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Preface 


This  report  is  published  in  the  interest  of  scientific  and  technical  information 
exchange;  the  ideas  and  findings  contained  herein  should  not  be  construed  as  an 
official  position  of  the  U.S.  Army  Corps  of  Engineers.  Use  of  any  trademarks  in 
this  report  is  not  intended  in  any  way  to  infringe  on  the  rights  of  the  trademark 
holder. 

While  much  work  has  gone  into  the  development  of  this  report,  it  should  be 
emphasized  that  it  is  introductory,  not  comprehensive,  in  nature;  doubtless  there 
are  questions  related  to  Ada  which  have  gone  unanswered.  Nevertheless,  after 
reading  this  document  managers  should  be  aware  of  the  broad  issues  associated 
with  the  transition  and  of  the  resources  available  when  further  investigation  is 
necessary. 

Much  of  the  information  presented  here  is  drawn  from  a  study  conducted  by 
Dr,  Orville  E.  Wheeler.  Memphis  State  University,  which  specifically  addressed 
the  transition  of  PC-targeted  systems  development  from  a  C,  C-Seape,  dbVista 
environment  to  an  environment  based  on  Ada  (Wheeler  1992).  Ms.  Lynn  Miku- 
lich.  Construction  Engineering  Research  Laboratory  (CERL),  contributed  to  the 
description  of  the  Rational  Environment,  and  Mr.  Ralph  Kahn.  Oracle  Corpora¬ 
tion.  to  the  discussion  on  Ada/Oracle  interfaces.  Dr.  Windell  F.  Ingram  reviewed 
this  report  and  made  many  helpful  comments.  The  author  gratefully  ack¬ 
nowledges  the  contributions  of  all  these  individuals.  Where  noted,  information 
has  been  drawn  from  the  Ada  Information  Cleari  ghouse  (AdalC). 

Tiiis  repcn  was  prepared  under  the  auspices  of  the  Executive  Software  Sub¬ 
committee  established  by  the  Field  Information  Management  User's  Group 
(FIMUG)  of  the  US  Army  Corps  of  Engineers  (USACE).  FIMUG  is  a  field 
advisory  body  to  the  Director  of  Information  Management.  The  Executive 
Software  Subcommittee  was  assigned  the  task  of  preparing  a  repon  giving  back¬ 
ground  on  and  discussing  issues  relevant  to  the  mandated  transition  to  the  Ada 
programming  language.  This  report  completes  that  task. 

The  production  of  this  report  was  sponsored  by  the  U.S.  Army  Environmental 
Center  (AEC)  and  funded  through  the  U.S.  Army  Engineer  Waterways  Experi¬ 
ment  Station  (WES)  Information  Technology  Laboratory  (ITL)  under  Contract 
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No.  DACW39-93-K-0016  from  March  3, 1993  to  December  31,  1993. 


Mr.  Mark  N.  Bovelsky  was  Chief  of  the  Information  Management  Branch, 
AEC,  and  also  Chairman  of  the  Executive  Software  Subcommittee  of  the 
FIMUG  during  the  preparation  of  this  report.  The  contract  was  monitored  by  Dr. 
Windell  F.  Ingram,  Chief,  Computer  Sciences  Division,  ITL.  Dr.  N.  Radhakrish- 
nan  was  Director,  ITL,  Dr.  Robert  W.  Whalin  was  Director  of  WES,  and  COL 
Bruce  K.  Howard,  EN,  was  Commander. 
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1  Executive  Summary 
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This  report  addresses  issues  relevant  to  the  transition  to  the  use  of  Ada  from  a 
Corps  of  Engineers  perspective.  The  direct  discussion  of  these  issues  is  pre¬ 
ceded  by  background  material  on  Ada  itself.  First,  the  Department  of  Defense 
(DoD)  software  crisis  that  led  to  the  development  of  Ada  is  described  and  the 
causes  underlying  it  are  presented.  Potential  solutions  to  the  crisis  are  discussed, 
including  programmer  productivity  aids,  structured  programming,  standardiza¬ 
tion  efforts,  computer-aided  software  engineering  (CASE)  tools,  and  research 
centers.  Next,  a  brief  history  of  Ada  is  presented  to  show  how  it  fits  into  the 
Government’s  approach  to  meeting  the  crisis.  This  includes  a  description  of  the 
systematic  design  and  review  process  to  which  preliminary  versions  of  Ada  were 
subjected,  followed  by  a  discussion  of  the  guidelines  which  apply  to  the  use  of 
Ada,  including  the  Congressional  mandate  to  use  Ada  and  the  pertinent  DoD  and 
Army  regulations. 

The  second  major  section  of  this  report  discusses  the  Corps  transition  to  Ada. 
This  transition  will  involve  not  only  a  change  in  the  programming  language  used 
by  the  Corps,  but  also  a  change  in  development  philosophy;  software  engineer¬ 
ing  principles  must  be  incorporated  into  the  development  process  for  the  transi¬ 
tion  to  be  successful.  The  various  issues  to  be  addressed  by  the  Corps  in  order  to 
accomplish  this  are  then  presented.  The  first  of  these  is  the  selection  of  a  com¬ 
piler  for  PC  platforms.  This  issue  is  discussed  using  results  drawn  from  a 
Corps-sponsored  study  which  reviewed  various  Ada  compilers  and  development 
tools.  The  importance  of  formal  training  for  programming  staff  is  stressed.  A 
four-week  sequence  of  courses  is  proposed  which  covers  object-oriented  design, 
Ada  coding,  and  object-oriented  analysis.  Other  aspects  of  training,  including 
attendance  at  technical  conferences  and  acquisition  of  relevant  literature,  are 
also  discussed.  Because  of  their  importance  to  the  Corps  during  the  Ada  transi¬ 
tion,  two  special  topics  are  then  addressed:  the  Rational  Environment  (a  state- 
of-the-art  Ada  programming  support  environment)  and  use  of  Ada  with  the  Ora¬ 
cle  RDBMS.  C  ASE  tools  will  have  to  be  acquired  to  support  this' effort;  exam¬ 
ples  of  such  tools,  including  code  production  environments,  screen  generators, 
database  managers,  analysis  and  design  aids,  and  metrics  collectors,  are 
described  to  illustrate  the  range  of  capabilities  available. 
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The  report  concludes  with  recommendations  concerning  practical  steps  Corps 
development  sites  can  take  to  ensure  a  successful  transition  to  the  use  of  Ada. 
The  most  immediate  of  these  are  acquisition  of  Ada  compilers  and  programming 
support  environments,  initiation  of  a  training  sequence,  selection  of  Ada  experts 
at  each  site,  and  making  a  decision  regarding  acquisition  of  the  Rational 
Environment.  An  important  long-range  recommendation  would  be  for  the  vari¬ 
ous  development  sites  to  successfully  participate  in  the  Software  Engineering 
Institute’s  (SEI)  Software  Process  Assessment.  As  a  final  note,  readers  should 
view  the  mandate  to  use  Ada  as  an  opportunity  for  the  Corps  to  assume  a  leader¬ 
ship  role  within  the  Army  in  the  area  of  software  development.  The  Corps  of 
Engineers  has  a  long  history  of  engineering  many  things  well,  and  there  is  no 
reason  why  the  Corps  should  not  engineer  software  well.  too. 
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Past  Problems 

Government  activities  depend  increasingly,  if  not  totally,  on  information 
technology  for  their  successful  completion.  Because  declining  appropriations 
are  forcing  reductions  in  manpower  while  workloads  continue  to  increase,  this 
dependence  will  accelerate  as  functional  organizations  automate  more  and  more 
tasks.  This  will  in  turn  increase  the  workload  of  infoimation  management  (IM) 
as  they  aid  these  organizations  in  this  automation  process.  Unfortunately,  IM  is 
not  immune  from  current  budgetary  pressures;  as  a  result,  it  must  automate  its 
own  software  development  activities. 

This  fiscal  difficulty,  although  serious  enough  in  and  of  itself,  is  not  the  only 
problem  faced  by  software  developers,  There  is  another  which  has  plagued  IM 
for  many  years  and  which  manifests  itself  in  software  systems  which  are 
delivered  years  late,  which  are  delivered  without  all  of  the  required  capabilities, 
or  which  are  not  delivered  at  all.  Furthermore,  many  such  systems,  even  those 
which  meet  their  functional  specifications,  perform  at  unacceptable  levels 
because  they  are  designed  for  and  in.stalled  on  computer  systems  of  insufficient 
power.  To  determine  the  extent  of  this  problem,  the  US  General  Accounting 
Office  conducted  a  study  of  nine  software  development  contracts  totaling  $6.8 
million  (U.S.  General  Accounting  Office  1979,  p.  11).  The  results  were  not 
encouraging: 

•  $3.2  million  was  spent  on  software  delivered  but  never  successfully  used. 

•  $1.95  nnillion  was  spent  on  software  paid  for  but  not  delivered. 

•  $1.3  million  was  spent  on  software  used  but  extensively  reworked  or  later 
abandoned. 

•  $198,000  was  spent  on  software  that  could  be  used  after  changes. 
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•  $1 19,000  v/as  spent  on  software  that  could  be  used  as  delivered, 

Furthermore,  the  average  delay  on  these  contracts  was  an  additional  75  percent 
of  the  original  time  estimate.  Unfortunately,  there  is  little  evidence  that  the 
situation  has  improved  since  this  study  was  performed. 

There  are  several  reasons  for  this  system  development  crisis.  First,  many  pro¬ 
ject  managers  are  optimistic  when  specifying  the  scope  of  a  project  because  they 
want  to  solve  as  many  of  their  IM  problems  as  possible.  Second,  reaching  con¬ 
sensus  on  automation  needs  is  time-consuming;  the  current  method  involves  iso¬ 
lating  key  personnel  at  a  remote  site  for  one  or  more  months  to  analyze  needs 
and  produce  requirements.  This  is  disruptive  to  work  at  the  home  sites  and  there 
is  still  no  guarantee  that  significant  changes  in  these  requirements  will  not  be 
necessary.  Third,  contractors  have  little  incentive  to  limit  project  scope,  because 
the  more  objectives  there  are,  the  more  money  there  is  to  be  made.  Fourth,  even 
if  Government  project  managers  are  realistic  in  their  estimates  of  what  can  rea¬ 
sonably  be  done  in  a  given  period  of  time,  they  generally  do  not  have  the  techni¬ 
cal  expertise  or  the  time  to  ascertain  if  the  contractor  is  following  accepted 
software  development  practices,  much  less  using  appropriate  modem  software 
engineering  methodology.  Furthermore,  contractor  personnel  who  actually 
design  and  implement  the  system  raiely  have  sufficient  software  engineering 
experience  because  software  engineering  is  not  viewed  as  an  important  part  of 
the  computer  science  curriculum  at  many  universities  (Frakes,  Fox,  and  Nejmeh 
1991,  p.  3). 


Potential  Solutions 

The  computing  community  has  long  recognized  the  need  to  facilitate  the 
timely  production  of  large  software  systems.  Many  of  these  have  focused  on 
improving  the  productivity  of  individual  programmers,  including  the  invention  of 
assemblers  (to  replace  the  use  of  machine  language),  compilers  for  third  genera¬ 
tion  high-level  languages  (to  replace  the  use  of  assemblers),  fourth-generation 
language  processors  (to  replace  use  of  compilers),  full-screen  language-specific 
editors  (to  replace  use  of  keypunches  and  line  editors),  the  use  of  source  code 
version  control  tools  such  as  make  and  sees  (to  reduce  the  complexity  of  the 
edit-compile-test  cycle),  and  the  use  of  structured  programming  (to  reduce  the 
complexity  of  the  software  itself). 

The  Government  has  also  initiated  a  number  of  efforts  to  resolve  the  software 
development  crisis.  Perhaps  the  most  successful  of  these  are  the  standardization 
activities,  including  the  establishment  and  ongoing  revision  of  the  Federal  Infor¬ 
mation  Processing  Standai'ds  (FIPS)  (NIST  1991)  by  the  National  Institute  for 
Standards  and  Technology  (NIST,  formerly  the  National  Bureau  of  Standards); 
these  FEPS  address  issues  ranging  from  hardware  data  formats  to  programming 
language  features.  More  recent  efforts  at  standardization  include  the  required 
use  of  Ada  for  all  new  DoD  software  projects  and  the  establishment  of  standard 
documentation  formats  (DoD-STD-2167/2167A).  Other  organizations  are  also 
active  in  this  process,  including  the  Institute  for  Electrical  and  Electronic 
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Engineers  (IEEE),  which  has  promulgated  standards  for  software  engineering 
and  software  quality  assurance  (IEEE  1983,  IEEE  1984,  IEEE  1986),  as  well  as 
the  American  National  Standards  Institute  (ANSI),  and  the  International  Stan¬ 
dards  Organization  (ISO),  which  have  produced  standards  for  various  program¬ 
ming  languages.  Finally,  there  are  de  facto  standards  which  exist  by  virtue  of 
their  widespread  use;  examples  include  operating  systems  (DOS,  MVS,  and 
UNIX)  window  environments  (Microsoft  Windows  and  the  X  Winoow  System), 
rnd  printer  control  languages  (HPPCL  and  PostScript). 

Unfortunately,  use  of  programmer  productivity  aids  is  tactical  in  nature 
because  it  addresses  only  the  implementation  phase  of  the  software  life  cycle. 
The  standardization  efforts  are  an  example  of  a  more  globa.l  approach,  but 
enforcing  use  of  such  standards  by  contractors  is  sometimes  difficult  for  non¬ 
technical  personnel,  and  in  any  case  such  efforts  do  not  go  far  enough  toward 
addressing  the  real  issues.  V^hat  is  needed  is  a  more  strategic  approach;  experts 
in  both  the  academic  and  commercial  worlds  Lave  recognized  tfis  and  a  number 
of  possible  approaches  have  been  proposed,  including  groupware  (GW), 
computer-aided  software  engineering  (CASE)  tools,  object-oriented  design 
(OOD),  object-oriented  programming  (OOP),  and  rapid  prototyping. 

DoD  has  recognized  the  potential  of  such  methods  and  has  established 
several  centers  to  encourage  further  software  engineering  reseai  ch  and  to 
transfer  this  technology  to  DoD  projects.  These  centers  include  the  SFl,  at 
Camegie-Mellon  University  in  Pittsburgh,  the  US  Army  Software  Engineering 
Directorate  at  Fort  Monmouth,  the  US  Army  Institute  for  Research  in  Manage¬ 
ment  Information,  Communications,  and  Computer  Science  (AIRMICS)  at  the 
Georgia  Institute  of  Technology,  and  the  US  Air  Force  Software  Technology 
Support  Center  (STSC)  at  Hill  Air  Force  Base.  Other  DoD  programs  that  address 
software  engineering  issues  include  the  Software  Technology  for  Adaptable, 
Reliable  Systems  (STARS)  Joint  Program  Office,  partially  sponsored  by  the 
Defense  Advanced  Researched  Projects  Agency  (DARPA),  and  the  Data  and 
Analysis  Center  for  Software,  which  provides  the  DoD  with  data,  information, 
products,  and  services  in  order  to  facilitate  technology  transition. 


A  History  of  Ada 

Why  has  Ada  been  selected  by  DoD  as  the  required  high-order  language? 
How  does  it  fit  into  the  solution  approach  described  above?  To  answer  these 
questions,  some  background  on  the  histor)'  of  Ada  is  required.  A  study  per¬ 
formed  during  1973  and  1974  revealed  that  the  Department  of  Defense  was 
spending  $3  billion  per  year  on  software,  that  this  cost  was  steadily  rising,  and 
that  most  of  the  cost  was  consumed  not  by  development  of  new  systems,  but  by 
maintenance  of  old  systems.  The  reasons  for  this  were  apparent;  DoD  software 
projects  were  so  specialized  that  the  contractor  who  originally  develoned  the 
system  was  almost  invariably  the  only  one  who  could  maintain  it,  thus  limiting 
competitiveness  and  eliminating  any  incentive  to  cut  costs  (Cohen  1986,  p.  2). 
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A  second  problem  was  the  use  of  obsolete  programming  languages.  Because 
these  languages  were  developed  in  the  1960s,  they  do  not  provide  features  to 
support  modem  software  development  concepts,  particularly  top-down  design, 
structured  programming,  data  abstraction,  module  reuse,  and  program  validation. 
Furthermore,  they  do  not  allow  interface  checking  between  separately  compiled 
program  modules,  and  assembly  language  must  often  be  used  for  device-level 
I/O  to  compensate  for  the  language’s  deficiencies  in  that  area  (Cohen  1986,  p.  2). 

This  situation  was  further  aggravated  by  frequent  contractor  use  of  project- 
specific  programming  languages  or  platform-specific  versions  of  “standard” 
languages.  This  discouraged  development  of  software  tools  because  their  one¬ 
time  use  could  not  justify  the  initial  cost  of  their  production.  Even  when  some 
simple  tools,  such  as  compilers,  linkers,  editors,  and  configuration  managers, 
were  developed,  they  were  typically  not  used  on  multiple  projects  (Cohen  1986, 

p.2). 

The  findings  of  the  1973-1974  study  led  to  the  establishment  of  the  High 
Order  Language  Working  Group  (HOLWG),  which  was  charged  with  identifying 
a  standard  language  for  use  throughout  DoD,  particularly  for  embedded  systems. 
The  HOLWG  included  members  from  the  Office  of  the  Secretary  of  Defense,  all 
three  branches  of  the  militai'y,  the  DARPA,  the  Defense  Communications 
Agency,  and  the  National  Security  Agency.  The  initial  requirements  for  this 
language,  tentatively  named  DoD-1,  were  released  in  April  1975  and  circulated 
within  the  Government  and  to  selected  outside  experts  in  the  field  of  program¬ 
ming  languages.  This  requirements  document,  termed  “Strawman,”  was  subse¬ 
quently  revised  to  produce  “Woodenman”  in  August  1975  and  “Tinman"  in 
January  1976;  each  revision  incorporated  recommendations  provided  by 
reviewers  from  government,  industry,  and  academia.  After  further  study,  the 
HOLWG  announced  in  January  1977  that  no  existing  language  satisfied  the  Tin¬ 
man  requirements.  The  Tinman  requirements  were  rewritten  in  the  form  of  an 
actual  language  specification,  dubbed  “Ironman,”  and  an  RFP  for  a  language 
design  was  released  in  April  1977.  Following  an  incremental  review  spanning 
two  years  in  which  the  number  of  designs  was  narrowed  from  seventeen  to  four 
to  two,  the  design  proposed  by  CII-Honeywell  Bull  was  accepted.  The  formal 
lariguage  specification  was  ultimately  published  in  1983  as  ANSl/MIL-STD- 
18 15  A- 1983.  and  as  a  FIPS  (NIST  1985). 

Since  the  standardization  of  the  Ada  language  specification  in  1983,  DoD  has 
steadily  moved  towards  adopting  Ada  as  r/it  standard  language  for  systems 
development.  Initially,  requirements  for  the  use  of  Ada  applied  only  to  embed¬ 
ded  weapons  systems.  Even  then,  it  was  sometimes  possible  to  obtain  waivers  to 
these  requirements.  However,  concerns  about  runaway  software  development 
costs,  coupled  with  the  recognition  that  use  of  Ada  throughout  DoD  would  result 
in  major  cost  savings,  prompted  more  stringent  regulations.  On  2  April  1987, 
DoD  issued  Directive  3405.1  which  stated. 

The  Ada  programming  language  shall  be  the  single,  common,  com¬ 
puter  programming  language  for  Defense  computer  resources  used 
in  intelligence  systems,  for  the  command  and  control  of  military 
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forces,  or  as  an  integral  part  of  a  weapons  system.  Programming 
languages  other  than  Ada  that  were  authorized  and  being  used  ii. 
full-scale  development  may  continue  to  be  used  through  deploy¬ 
ment  and  for  software  maintenance,  but  not  for  major  software 
upgrades.  Ada  shall  be  used  for  all  other  applications,  except  when 
the  use  of  another  approved  higher  order  language  is  more  cost- 
effective  over  the  application's  life-cycle,  in  keeping  with  the 
long-range  goal  of  establishing  Ada  as  the  primary’  DoD  higher 
order  language  (HOL)  (U.S.  Department  of  Defense  1987). 

In  this  context,  a  major  softwuie  upgrade  is  defined  to  be  “redesign  or  addition 
of  more  than  one-third  of  the  software.*’  i  he  complete  text  of  this  directl'  e  is 
given  in  Appendix  A. 

HQDA  emphasized  the  Army’s  adherence  to  this  policy  in  LTR  25-90-1, 
issued  on  16  July  1990,  which  specifically  addressed  “Implementation  of  the 
Ada  Programming  Language."  This  letter  stated. 

The  Ada  programming  language  as  defined  in  ANSI/MIL-STD- 
1815A-1983  is  the  single,  common,  high  order  computer  program¬ 
ming  language  for  all  computer  resources  used  in  the  Army  unless 
another  language  is  mandated  by  a  higher  level  directive.  Existing 
software  need  not  be  rewritten  in  Ada  solely  for  the  purpose  of 
converting  to  Ada.  All  systems,  however,  will  transition  to  Ada 
when  the  next  hardware/software  upgrade  requires  modification  of 
more  than  one-third  of  the  existing  code  over  the  system  life  cycle, 
unless  a  waiver  is  obtained  (U.S.  Department  of  the  Army  1990). 

Waivers  are  not  necessary  for  use  of  (1)  off-the-shelf  software  requiring  no 
Government  maintenance  or  modification,  (2)  SQL  as  an  interface  to  a  DBMS, 
(3)  non-SQL-compliant  4GLs  to  produce  prototypes  or  systems  with  a  useful  life 
of  less  than  3  years,  and  (4)  machine  or  assembly  language  in  performance  criti¬ 
cal  situations  when  the  ratio  of  non- Ada  to  Ada  source  code  does  not  exceed 
15%  and  the  non- Ada  code  is  not  more  than  10,000  lines.  All  other  situations 
require  waivers.  Requests  for  waivers  must  be  accompanied  by  a  thorough  cost 
and  technical  analysis  which  clearly  demonstrates  the  cost  effectiveness  of  the 
proposed  language.  The  complete  text  of  this  letter  is  given  in  Appendix  B. 

Finally,  on  5  November  1990,  the  President  signed  the  FY  1991  DoD 
appropriations  bill  (Pu'olic  Law  101-511)  Section  8092  of  this  law,  popularly 
known  as  the  “Ada  Mandate,”  states. 

Notwithstanding  any  other  provisions  of  law,  after  June  1,  1991 , 
where  cost  effective,  all  Department  of  Defense  software  shall  be 
written  in  the  programming  language  Ada,  in  the  absence  of  special 
exemption  by  an  official  designated  by  the  Secretary  of  Defense.” 

(U.S.  Congress  1990) 
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Supporting  inforniation  on  this  law.  is  given  in  Appendix  C 


The  Superiority  of  Ada 

Kcsponiais  to  these  policy  statements  from  the  software  development  com¬ 
munity  have  often  been  quite  skeptical,  and  many  still  question  Ada's  purported 
cost  benefits.  From  a  scientific  perspective,  one  of  the  strongest  challenges  has 
come  from  adherents  of  object-onented  design  lOOD)  and  object-oriented  pro¬ 
gramming  (OOP).  This  relatively  recent  technology  empha.sizes  the  correspon¬ 
dence  between  objects  and  operations  m  the  real  world  and  data  types  and  opera¬ 
tions  in  a  software  system.  It  promises  order-of-magnitude  improvements  in 
software  development  productivity.  Although  object-onented  principles  and 
methodologies  are  generally  language  independent,  several  languages  have  been 
designed  to  provide  object-onented  features.  Smalltalk,  at  the  same  time  a  pro¬ 
gramming  environment  and  a  programming  language,  is  preeminent  in  this 
respect.  It  claims  to  be  a  pure  object-oriented  language,  but  it  typically  makes 
heavier  demands  on  system  resources  than  general-purpose  procedural 
languages,  and  few  large  software  systems  have  been  implemented  in  it.  How¬ 
ever,  these  particular  criticisms  are  not  valid  for  Ada's  strongest  challenger, 

This  language  was  designed  to  directly  support  object-oriented  techniques 
and  at  the  same  time  be  completely  upward  compatible  with  C.  In  an  attempt  to 
obtain  a  waiver  to  the  use  of  Ada,  the  Air  Force  conducted  a  study  to  determine 
the  relative  cost  effectiveness  of  Ada  and  C-i-f-  (U.S.  Department  of  the  Air  Force 
1991).  (An  overview  of  the  Air  Force  report  is  given  in  Appendix  D.)  Surpris¬ 
ingly,  the  study  determined  the  opposite  of  what  many  anticipated;  Ada,  not 
C-i")-,  was  found  to  be  superior. 

This  study  consisted  of  four  substudies  which  compared  the  two  languages 
from  various  perspectives.  The  first  substudy,  performed  by  the  Institute  for 
Defense  Analyses  (IDA),  addressed  tools,  environments,  and  training.  Their 
report  concluded  that  there  are  more  US  vendors  of  Ada  compilers  than  C-t-H 
compilers  (28  vs.  1 8),  that  Ada  compilers  are  subjected  to  a  relatively  rigorous 
validation  process  whereas  C-i-f-  compilers  cannot  be  validated  because  no  C-n- 
standaxd  even  exists,  that  Ada  has  cross-compilation  systems  and  code  genera¬ 
tors  while  C-i"H  does  not,  and  that  223  universities  and  13  DoD  installations  teach 
Ada  compared  to  4  and  0.  respectively,  for  C-t-+.  The  second  substudy  was  con¬ 
ducted  by  the  SEI  and  included  a  quantitative  comparison  of  the  two  languages 
based  on  six  categories:  capability,  efficiency,  availability/reliability, 
maintainability/extensibility,  life  cycle  cost,  and  risk.  Ada  was  clearly  superior 
by  a  score  of  78.8  to  63.9  (on  a  100-point  scale).  The  third  substudy,  completed 
by  CTA,  concluded,  “Ada  projects  have  reported  15%  higher  productivity  with 
increased  quality  and  double  the  average  size.  Normalizing  these  data  to  com¬ 
parable  size  projects  would  result  in  an  expected  Ada  productivity  advantage  of 
about  35%.’’  Specifically,  their  data  indicated  that  C-f-i-  suffered  from  error  rates 
three  times  greater  than  Ada  (as  measured  at  the  software  formal  qualification 
test).  The  final  study,  performed  by  TRW,  established  18  criteria  to  judge  the 
life  cycle  cost  effectiveness  of  the  two  languages.  A  panel  of  experts  was  then 
used  to  establish  the  scores  and  weights  for  each  of  these  criteria;  the  score  for 
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Ada  was  higher  for  MIS  systems  and  24%  higher  for  C'^  systems.  The 
study's  overall  conclusions  are  given  below. 

All  four  substudies  whic!.  specifically  compared  Ada  and  C++ 

(IDA.  SEl,  CTA,  TRW  i  report  a  significant  near  term  Ada  advan¬ 
tage  over  C++  for  all  categories  of  .systems.  This  advantage  could 
be  eroded  as  C++  and  its  supporting  environments  mature  over  the 
next  few  years.  On  the  other  hand,  as  aggressive  overseas  Ada  ini¬ 
tiatives  stimulate  even  wider  domestic  Ada  interest,  a.s  Ada 
tools/cnvironments  further  mature,  and  when  the  Ada  update  (Ada 
9X)  is  complete,  the  balance  could  tip  further  in  Ada’s  favor. 

Adding  to  the  case  for  Ada  is  that  the  Ada  scoring  so  well  herein  is 
Ada’s  1983  version,  MIL-STD-1815A.  Just  as  C++  incorporates 
into  C  certain  software  engineering  concepts  already  in  Ada  (e.g., 
modularity,  strong  typing,  specification  of  interfaces),  so  an  Ada 
update  now  underway  will  bring  into  Ada  selected  features  now 
included  in  C++.  This  update,  known  as  the  Ada  9X  Project,  is  tar¬ 
geted  for  completion  in  1993  (Ada  9X  Project  Office  1991).  The 
product  of  extensive  community  involvement  (including  the  and 
MIS  communities),  Ada  9X  will  bring  to  Ada  such  improvements 
as  decimal  arithmetic,  international  character  sets,  improved 
input/output,  support  for  calls  between  Ada  and  other  languages, 
further  representation  specifications,  and 
inheritance/polymorphism  (popular  features  of  C++).  At  the  same 
time,  Ada  9X  has  been  designed  so  that  neither  existing  Ada 
benefits  nor  performance  will  be  lost.  For  example,  Ada  9X  inheri¬ 
tance  will  be  controlled  so  as  not  to  reduce  life  cycle  supportabil- 
ity. 

In  summary,  Ada  is  the  most  cost  effective  programming  language 
for  DoD  applications.  Specifically,  it  is  not  possible  to  make  a 
credible  case  for  the  existence  of  classes  of  ’’more  cost  effective” 
C++  systems  compared  to  Ada.  Business  cost  effectiveness  data 
collected  for  this  study  are  typified  by  the  TRW  conclusion  that 
Ada  provides  development  cost  advantages  on  the  order  of  35% 
and  maintenance  cost  advantages  on  the  order  of  70%.  In  terms  of 
future  life  cycle  costs,  it  will  be  some  time  before  data  exists  which 
could  justify  a  cost  savings  for  C++.  Today,  there  is  limited  life 
cycle  data  available  for  Ada  and  almost  none  for  C++. 

For  the  foreseeable  future,  then,  there  are  more  than  enough  rea¬ 
sons  for  the  DoD  to  stick  firmly  with  Ada  for  all  high  order 
language  (3GL  and  3-1/2  GL)  development  and  for  exclusive  use 
as  a  target  language  of  4GL  application  generators  in  the  large 
class  of  applications  for  which  3GL  code  must  supplement  gen¬ 
erated  code  (U.S.  Department  of  the  Air  Force  1991). 
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These  conclusions  carry  particular  weight  for  the  Corps  when  one  notes  that 
the  study  focused  on  information  and  systems  (not  embedded  weapons  sys¬ 
tems),  and  that  those  who  initiated  the  study  were  biased  toward  C-t-t-  and  against 
Ada. 
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3  The  Corps  Transition  to  Ada 


Scope  of  the  Transition 

Without  the  Ada  mandate,  the  Corps  would  have  three  alternatives  in  the  area 
of  programming  language  selection:  to  stay  with  whatever  is  currently  in  use,  to 
adopt  a  more  modem  language  other  than  Ada,  or  to  adopt  Ada.  The  first 
approach  has  been  tried  for  over  a  quarter  century  and  has  proven  ineffective. 
The  most  promising  choice  for  the  second  alternative.  C++,  is  still  immature, 
lacking  a  standard  and  associated  development  tools.  Ada,  the  third  choice,  has 
proven  its  effectiveness  in  numerous  large  projects,  has  a  standard  which  has 
been  in  place  almost  ten  years  and  which  is  rigorously  monitored,  and  has  a  wide 
variety  of  tools  which  are  available  to  assist  programmers  and  analysts.  Even  if 
the  Government  had  not  required  the  transition  to  Ada,  there  would  still  be  many 
compelling  reasons  to  do  so,  and  no  compelling  reasons  not  to  do  so.  Pursuing 
this  third  choice  will,  however,  have  a  price.  The  immediate  costs  will  be  asso¬ 
ciated  with  the  purchase  of  Ada  compilers  and  the  training  of  programmers. 
Learning  the  Ada  language  will  be  relatively  straightforward  for  those  develop¬ 
ers  who  are  already  experienced  with  Pascal  and,  to  a  lesser  extent,  C.  Those 
who  have  programmed  exclusively  in  FORTRAN  or  Cobol  will  typically  require 
a  longer  training  period. 

However,  if  the  transition  to  Ada  involved  only  a  change  in  programming 
language,  it  would  indeed  be  relatively  painless.  Unfortunately,  this  is  not  the 
case.  Additionally,  to  maximize  the  benefits  of  the  change,  recognized  software 
engineering  principles  must  be  incorporated  throughout  the  software  life  cycle. 
More  specifically,  the  underlying  methodology  used  by  project  leaders  to  design 
large  software  systems  must  be  changed;  the  leading  contender  for  this  metho¬ 
dology  is  the  object-oriented  approach  already  mentioned.  Secondly,  computer- 
aided  software  engineering  (CASE)  tools  must  be  acquired  to  automate  the 
development  process;  these  range  from  language-sensitive  editors  which  help 
minimize  syntax  errors  to  high-level  design  tools  which  facilitate  application  of 
an  object-oriented  methodology.  Finally,  application  programmers  and  analysts 
must  be  equipped  with  a  development  platform  which  has  greater  functionality 
than  the  curre  it  DOS-based  environment.  The  memory'  limitations  inherent  in 
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DOS,  the  absence  of  protected  mode  execution,  its  lack  of  virtual  memory,  its 
inability  to  support  multiple  users,  the  absence  of  true  multitasking  (even  with 
Windows),  and  its  inability  to  support  multiple  users  are  deficiencies  which  limit 
the  productivity  of  applications  developers.  That  Microsoft  recognizes  these 
shortcomings  is  evidenced  by  their  soon-to-be-released  NT  operating  system. 
Other  candidates  include  IBM’s  OS/2,  and  of  course,  the  more  mature  and 
nonproprietary  UNIX  operating  system.  However,  these  three  additional  issues 
would  need  to  be  resolved  regardless  of  the  language  selected:  furthermore,  they 
must  be  resolved  to  make  optimum  use  of  Ada  in  the  development  of  large 
software  systems. 


Compiler  Selection 

Many  computer  manufacturers  provide  compilers  for  their  own  systems  while 
other  software  companies  have  produced  cross  compilers  primarily  for  embed¬ 
ded  systems.  From  the  Corps’  perspective,  however,  there  are  currently  three 
major  independent  Ada  compiler  vendors;  Alsys,  Telesoft,  and  Verdix.  Of  these 
three,  Alsys  is  probably  the  vendor  of  choice  for  the  Corps’  Control  Data  (CD) 
and  PC  platforms,  although  the  Verdix  VADS  environment  is  probably  better  for 
RISC  workstations  (SR A  1992).  Alsys  offers  compilers  for  a  broad  range  of 
hardware  platforms,  including  IBM-compatible  PCs  running  DOS  and  UNIX, 
various  Motorola  68000-based  computers  (Apple  Macintoshes,  Apollo  Domain 
workstations.  HP  9(K)0/3CK)s,  and  Sun-3s),  most  RISC-based  workstations  and 
servers  (DECstations,  IBM  RS/6000s.  MIPS,  and  Sun  SPARC),  DEC  VAX/VMS 
workstations  and  minicomputers,  and  IBM  370  series  mainframes.  The  plat¬ 
forms  of  particular  interest  to  the  Corps  are  80X86  tunning  DOS,  to  be  discussed 
below,  and  the  Control  Data  4000  series.  Control  Data  has  licensed  the  Alsys 
Ada  compiler  for  MIPS-based  systems  and  has  placed  it  on  the  Corps  of 
Engineers  Automation  Plan  (CEAP)  contract.  This  product  consists  of  a  compi¬ 
lation  system,  which  includes  the  Ada  compiler,  global  optimizer,  linker,  library 
manager,  run-time  executive,  standard  Ada  packages,  and  an  ISO-compliant 
math  library,  as  well  as  a  tool  set,  which  includes  a  source-level  symbolic 
debugger,  recompiler  to  automate  the  system  rebuilds,  cross  reference  generator, 
source  code  reformatter  with  user-controllable  options  to  enforce  particular  cod¬ 
ing  standards,  syntax  checker,  source  generator  to  produce  source  code  from 
compilation  units,  name  expander  to  convert  identifiers  visible  through  use 
clauses  into  fully  qualified  names,  and  profiler  to  determine  where  execution 
time  is  spent.  Pertinent  contract  information  is  given  in  Table  1 . 

Many  Corps  programmers  will  initially  use  80X86/DOS  platforms  for  their 
development  work.  Although  there  are  over  270  validated  Ada  compilers  avail¬ 
able  today,  only  three  run  under  MS-DOS:  FirstAda  from  Alsys,  OpenAda  from 
Meridian  Software  Systems  (recently  purchased  by  Verdix),  and  Janus/Ada  from 
R&R  Software.  As  part  of  a  Corps-sponsored  study  (Wheeler  1992),  these  three 
compilers  were  compared  using  cost,  documentation,  adherence  to  standard, 
resources  required,  support  environment  availability,  vendor  history  and  future, 
upward  migration,  and  performance  as  evaluation  criteria.  The  evaluations  were 
based  on  published  reports  in  trade  Journals,  personal  communication  with 
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Table  1 

Ada  Compilers  on  the  CEAP  Contract 

CEAP 

Contract 

Initial 

Monthly 

Computer 

Una  Item 

Licanae 

Maint. 

System 

Number 

Coat 

Charge 

CD  4330 

1075TJ 

$15,000 

$250 

CD  4680 

1075TK 

$20,000 

$335 

vendor  representatives,  documentation  supplied  with  each  product,  actual  bench¬ 
marks  performed  for  this  study,  as  well  as  personal  experience  with  each  of  the 
compilers.  Each  of  the  three  compilers  was  assigned  a  score  from  1  to  10  for 
each  criterion  and  weights  indicating  the  relative  importance  of  each  criterion 
were  then  used  to  produce  a  weighted  average.  A  complete  description  of  the 
evaluation,  including  rationale  for  the  scores  presented  here,  is  provided  in  the 
study’s  final  report  (Wheeler  1992).  The  results  displayed  in  the  Table  2  indicate 
the  superiority  of  Alsys  FirstAda  (A)  over  its  Meridian  (M)  and  R&R  (R)  com¬ 
petitors.  Its  documentation  and  performance  were  clearly  better  than  the  other 
two  while  recent  price  reductions  from  Alsys  make  cost  differences  negligible 
(Alsys’  volume  price  is  $973.50  each,  including  media,  documentation,  and  one 
year  of  maintenance). 


Table  2 

PC  Ada  Compiler  Comparioon'* 

Evaluation 

Criteria 

Raw  Scores 

_ _ _ _ 

Weight 

Factor 

Weighted  Scores 

A 

M 

R 

A 

M 

R 

Cost 

8 

9 

9 

5 

40 

45 

45 

Documentation 

9 

6 

2 

10 

90 

60 

20 

Standard 

9 

8 

6 

8 

72 

64 

48 

Resources 

6 

8 

9 

2 

12 

16 

18 

Environment 

8 

6 

7 

8 

64 

46 

56 

Vendor 

9 

7 

7 

7 

63 

49 

49 

Migration 

9 

6 

3 

5 

45 

30 

15 

Performance 

9 

6 

2 

10 

90 

60 

20 

Aggregate 

476 

372 

271 

Percent 

86.5 

67.6 

49.3 

1  From  (Wheeler  1992) 

As  a  final  comparison,  the  well-known  Whetstone  benchmark  (Cumow  and 
Wichman  1976)  was  used  to  compare  the  performance  of  Alsys  FirstAda,  Micro¬ 
soft  FORTRAN,  Borland  C,  and  Borland  Turbo  Pascal.  The  tests  were  per¬ 
formed  on  a  16  MHz  Zenith  386.  Using  a  full  math  library  with  run-time  check¬ 
ing  disabled,  the  results,  as  measured  in  thousands  of  Whetstone  instructions  per 
second,  were  767,  650,  572,  and  111.  Although  this  comparison  is  obviously  not 
exhaustive,  it  does  indicate  that  Ada  compilers,  at  least  as  exemplified  by  Firs¬ 
tAda,  are  competitive  with  other  available  language  compilers.  Again,  further 
information  on  this  benchmark  may  be  found  in  the  WES  report.  (Wheeler  1992) 


Chapter  3  The  Corps  Transition  to  Ada 


Personnel  Training 

As  noted  earlier,  because  a  successful  transition  to  Ada  will  involve  more 
than  just  changing  compilers,  so  will  training  programmers  to  use  Ada  involve 
more  than  teaching  Ada  syntax  and  semantics.  The  required  changes  in  thinking 
and  working  patterns  cannot  be  induced  in  software  developers  without  formal 
training.  This  approach  will  emphasize  to  the  students  the  importance  manage¬ 
ment  attaches  to  the  Ada  transition,  much  more  so  than  if  they  are  handed  a  book 
and  told  to  pick  up  the  technology  on  their  own.  This  training  should  develop  in 
personnel  a  new  perspective  on  the  design  of  large  software  systems  and 
encourage  the  incorporation  of  modem  software  engineering  practices  into  their 
development  projects.  Based  on  successful  experience  at  CERL,  THAMA,  and 
WES,  it  is  recommended  that  this  training  include  an  overview  of  the  software 
development  crisis  and  the  history  of  Ada  (two  days),  object-oriented  design 
with  Ada  (one  week),  coding  programs  in  Ada  (two  weeks),  and  object-oriented 
requirements  analysis  (one  week).  Modem  software  engineering  principles 
should  be  incorporated  into  every  course.  No  more  than  twenty  students  should 
be  in  any  class  and  only  personnel  having  prior  experience  with  another  pro¬ 
cedural  programming  language  should  attend.  At  least  one  or  two  weeks  should 
elapse  between  courses  to  prevent  students  from  becoming  overwhelmed  with 
new  information.  Managers  should  attend  the  design  and  analysis  courses  if  at 
all  possible.  System  development  work  in  Ada  should  follow  soon  after  the 
course  work  to  provide  immediate  positive  reinforcement  of  the  concepts  learned 
during  the  training.  When  a  large  project  is  envisioned  which  involves  develop¬ 
ment  teams  at  different  sites  simultaneously  making  the  transition  to  Ada,  a  com¬ 
mon  training  program  is  advised  to  provide  a  common  technical  vocabulary, 
design  methodology,  and  development  philosophy. 

The  purpose  of  the  initial  two-day  overview  session  should  be  to  motivate  the 
development  staff  for  participation  in  the  remaining  courses.  This  introduction 
should  cover  the  DoD  software  development  crisis  and  the  various  attempts 
within  the  software  engineering  community  to  address  it.  The  history  of  Ada 
should  be  given  to  present  the  language  as  an  essential  part  of  the  solution  to  this 
problem.  Ada  should  be  compared  to  other  programming  languages,  noting  its 
similarities,  its  unique  capabilities,  and  the  rigorous  standardization  process  to 
which  Ada  compilers  are  subjected.  Software  engineering  should  be  introduced 
not  as  the  application  of  an  array  of  CASE  tools,  but  as  the  application  of  good 
c  tgineering  management  principles  to  the  development  of  software,  i.e.,  under¬ 
standing  the  problem,  planning  the  solution,  constructing  the  design,  executing 
the  design,  and  communicating  the  solution.  The  need  to  change  from  “hand 
crafted"  software  to  “engineered"  software  should  be  stressed,  and  the 
improvements  in  understandability,  reliability,  maintainability,  and  efficiency 
which  will  result  from  this  change  should  be  noted.  Object-oriented  techniques 
should  be  introduced  as  a  tool  to  effect  this  transition.  Case  studies  should  be 
provided  to  illustrate  the  successful  use  of  Ada  in  the  development  of  large 
software  systems.  Students  should  be  impressed  with  the  notion  that  Ada’s 
overall  design  and  many  of  its  specific  features  were  intended  to  support 
software  engineering  principles  and  that  the  transition  to  Ada  should  be  viewed 
as  a  commitment  to  adopt  those  principles. 


14 


Chapter  3  The  Corps  Transition  to  Ada 


The  remaining  courses  are  intended  to  provide  the  necessary  knowledge 
about  the  language,  software  engineering,  object  technology,  and  the  develop¬ 
ment  environment  to  allow  programmers  to  begin  using  Ada.  The  object- 
oriented  design  (OOD)  course  should  cover  the  following  topics:  motivation  for 
using  object  classes  to  model  the  problem  space;  comparison  of  functional  and 
object  class  problem  decomposition;  introduction  to  object-oriented  design 
methodology  ;  material  necessary  to  introduce  the  notion  of  separate  compilation, 
including  Ada  program  units,  program  structure,  and  the  Ada  program  library; 
the  black-box  principle  for  information  hiding  and  data  abstraction,  including 
encapsulation,  packages,  and  private  types;  various  Ada  types,  including  integer, 
floating  point,  enumeration,  record,  array,  and  access  types;  generics  and 
predefined  units.  Case  studies  should  be  provided  to  illustrate  the  design  process 
and  how  to  critique  a  design.  Exercises  should  be  assigned  to  provide  experi¬ 
ence  in  the  use  of  Ada  as  a  program  design  language  (Tcxel  1992  Object- 
Oriented  Design  with  Ada).  The  Ada  coding  course  should  cover  the  following 
topics:  overview  of  the  syntax  of  various  Ada  statements;  Ada  identifiers;  sub¬ 
programs,  input/output,  and  exceptions;  more  in-depth  coverage  of  Ada  types 
than  was  provided  in  the  previous  course  including  when  to  use  distinct  types, 
subtypes,  and  predefined  types;  Ad?  control  structures:  loops,  if  statements,  case 
statements;  additional  information  on  generics;  tasking.  Class  time  should  be 
about  half  lecture  and  half  hands-on  work  on  coding  exercises  (Texel  1992  Ada 
Coding).  The  object-oriented  requirements  analysis  (OORA)  course  should 
cover  the  following  topics:  introduction  to  OORA:  comparison  with  other 
requirements  analysis  techniques;  role  of  object  classes,  attributes,  and  relation¬ 
ships  in  OORA;  use  of  state  and  process  models;  transition  to  the  design  stage. 
Practical  application  issues  should  be  addressed  through  case  studies  and  exten¬ 
sive  exercises  (Texel  1992  Object-Oriented  Requirements  Analysis).  The  fol¬ 
lowing  topics  from  software  engineering  should  also  be  covered  at  some  point  in 
the  course  sequence:  aims  of  software  engineering;  models  of  software  develop¬ 
ment;  requirements  definition  and  evolution;  design  processes  and  strategies; 
software  components  and  reusability;  programming  for  reliability,  including 
exception  handling  and  defensive  programming;  software  testing;  programmer 
productivity,  quality  control,  and  software  metrics. 


After  these  courses  are  completed,  steps  should  be  taken  to  maintain  staff 
expenise,  Programmers  should  be  encouraged  to  obtain  membership  in  the 
ACM,  ACM  SIGAda,  and  the  IEEE  Computer  Society.  If  possible,  the  organiza¬ 
tion  should  subscribe  to  relevant  publications  from  these  organizations,  as  well 
as  any  others  which  may  be  helpful.  A  recommended  list  would  include  Ado 
Letters,  CrossTalk,  Communications  of  the  ACM,  and  IEEE  Cc  .,;puter.  If  possi¬ 
ble,  ACM  Computing  Surveys ,  ACM  Transactions  on  Information  Systems,  ACM 
Transactions  on  Software  Engineering  and  Methodology,  IEEE  Software,  IEEE 
Transactions  on  Software  Engineering,  and  Software:  Practice  and  Experience 
should  be  added  as  well.  This  library  should  also  include  texts  and  conference 
proceedings  covering  Ada,  object-oriented  technology,  and  software  engineer¬ 
ing;  the  bibliography  at  the  end  of  this  repon  should  serve  as  a  starting  point  for 
this  effort. 
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A  few  individuals  should  be  selected  to  become  the  organization’s  Ada 
experts.  They  should  be  the  recipients  of  further  training  on  a  regular  basis,  stay 
aware  of  the  activities  of  the  Ada  Joint  Program  Office,  and  should  also  attend 
selected  conferences  and  seminars,  e.g.,  the  TRI-Ada  Symposium,  the  Washing¬ 
ton  Ada  Symposium,  and  the  Software  Technology  Conference.  Refer  to  Appen-  i 

dix  G:  Ada  Events  Calendar  for  a  more  complete  list  of  such  events.  Further-  j 

more,  they  should  become  familiar  with  Ada  related  resources  available  over  the 
Internet,  such  as  those  at  the  SEI,  the  Software  Technology  Support  Center,  and 
the  SIMTEL20  database;  these  include  technical  reports  as  well  as  repositories 
of  potentially  reusable  Ada  software  components.  The  catalog  by  Nyberg 
(Nyberg  1991)  will  be  of  particular  assistance  in  this  respect.  In  addition  to  their 
regularly  assigned  duties,  these  individuals  would  be  responsible  for  keeping 
abreast  of  advances  in  Ada  development  and  software  engineering  practice,  act¬ 
ing  as  consultants  for  the  rest  of  the  development  staff,  providing  introductory 
assistance  to  new  employees,  and  teaching  short  courses  as  necessary. 


The  Rational  Environment 

Every  software  system  is  implemented  in  three  environments,  the  decision 
environment,  the  design  environment,  and  the  coding  environment.  The  decision 
environment  is  that  in  which  the  system’s  requirements  are  specified;  here  deci¬ 
sions  are  made  regarding  how  much  of  a  process  should  be  automated,  what 
inputs  must  be  supplied  to  the  system,  how  those  inputs  are  to  be  obtained,  what 
outputs  the  system  will  produce,  how  those  outputs  are  to  be  presented,  and  how 
users  will  interact  with  the  system.  Generally,  input  into  this  decision-making 
process  is  provided  by  functional  managers  and,  occasionally,  by  prospective 
end-users  and  system  developers.  The  output  from  the  decision  environment 
provides  strategic  guidance  to  the  developers  of  the  system.  The  subsystems  are 
assigned  to  development  teams  who  may  actually  be  independent  contractors. 
These  teams  are  responsible  for  taking  the  broad  guidelines  supplied  to  them  and 
incrementally  refining  the  design  until  an  actual  working  system  is  obtained. 

'Fhe  organizational  and  computational  context  in  which  this  is  done  is  termed  the 
development  environment;  it  is  broken  into  two  subenvironments,  the  design 
environment  and  the  coding  environment.  In  the  former,  technical  managers 
make  decisions  regarding  breakdown  of  subsystems  into  packages  and  modules, 
and  the  information  flow  between  them,  while  in  the  latter,  programmers 
translate  the  design  into  actual  program  text,  which  is  then  compiled,  debugged, 
and  tested. 

There  are  numerous  potential  problems  in  this  process.  Because  the  magni¬ 
tude  of  these  problems  is  so  large  and  because  they  are  so  widespread,  each  is 
worthy  of,  and  is  being  addressed  by,  research  devoted  to  that  particular  field.  In 
each  case  experts  are  attempting  to  apply  increased  levels  of  automation  to  bring 
this  software  development  crisis  under  control;  within  the  first  environment,  the 
current  approach  involves  the  use  of  the  IDEF  methodology  (D.  Appleton  Com¬ 
pany  1992)  for  business  process  modeling  and  computer-supported  collaborative 
work  (CSCW)  techniques  such  as  electronic  meeting  .systems  (Johansen  1988) 
for  reaching  group  consensus;  within  the  second,  CASE  tools,  such  as  code 
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generators,  are  proposed;  within  the  third,  programmer  productivity  enhance¬ 
ments,  such  as  language  sensitive  editors,  have  been  applied. 

However,  even  if  satisfactory  solutions  are  found  to  the  problems  within  all 
of  these  environments,  the  maximum  benefit  will  not  be  obtained  unless  the  three 
environments  are  integrated.  The  issue  to  be  resolved  is  one  of  communication; 
each  environment  involves  a  different  group  of  people,  each  depending  on  feed¬ 
back  from  the  others  to  accomplish  their  objectives.  Seamless  interfaces 
between  these  environments  must  be  developed  to  facilitate  smooth  transfer  of 
knowledge  and  specifications.  THAMA  is  currently  sponsoring  research  at  WES 
to  remedy  this  situation.  This  work  involves  development  of  prototype  inter¬ 
faces  between  existing  solutions  (IDEF,  CSCW,  and  CASE)  to  make  progress  in 
a  timely  manner.  At  the  same  time  preliminary  investigations  are  under  way  to 
explore  the  feasibility  of  a  single  environment-spanning  software  system  to  pro¬ 
vide  such  an  integrated  environment. 

The  system  which  holds  the  most  promise  for  progress  in  this  area  is  the 
Rational  Environment™,  which  currently  addresses  the  coding  environment 
only.  Site  visits  to  Rational  user  sites  indicate  that  it  is  far  superior  to  all  other 
currently  available  systems  for  implementing  large  software  systems  in  Ada. 
Because  the  Rational  provides  a  programmable  interface  which  will  allow 
design  tools  to  communicate  with  it,  it  is  hoped  that  it  will  be  possible  to  extend 
its  area  of  applicability  to  the  first  two  environments.  Because  it  is  so  effective 
in  enhancing  programmer  productivity,  it  is  worth  elaborating  on  its  capabilities. 

The  Rational  Environment  (or  simply,  “the  Rational”)  is  an  integrated, 
interactive  software  engineering  environment  for  development,  testing,  mainte¬ 
nance,  and  control  of  large  Ada  projects.  It  replaces  the  usual  collection  of  edit, 
make,  and  version  control  utilities  with  a  completely  integrated  system  for  pro¬ 
gram  development.  For  performance  reasons,  the  compute  intensive  portion  of 
this  environment  executes  on  Rational’s  own  proprietary  hardware,  the  RIOOO 
processor.  This  environment  server  is  accessed  over  an  Ethernet  through  a 
software  interface  available  on  Sun  SPARC  and  IBM  RS/6000  workstations  tun¬ 
ning  the  X  Window  System,  as  well  as  PCs  running  Microsoft  Windows.  One 
such  RIOOO  processor  will  support  anywhere  from  five  to  fifteen  developers, 
depending  on  the  mix  of  editing  and  compilation.  An  influx  of  large  compilation 
jobs  degrades  the  system's  performance,  but  the  intelligence  built  into  the  system 
reduces  the  likelihood  of  such  a  situation. 

Use  of  the  Rational  on  a  large  project  begins  with  use  of  the  Rational  Design 
Facility  (RDF).  It  supports  the  requirements  analysis  and  design  phases  of  the 
software  life  cycle.  Ada  is  used  in  this  context  as  a  program  design  language 
(PDL)  for  requirements  capture,  software  design,  and  MLL-STD-2167A  compli¬ 
ant  document  generation.  The  RDF  also  supports  integration  with  third-party 
CASE  and  desk  top  publishing  software  packages,  including  Cadre  Teamwork'"^ 
and  Interleaf  TPS™. 

During  the  code  development  phase,  the  Rational  provides  an  intuitive 
window-based  interface  which  allows  users  to  browse  Ada  systems  according  to 
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syntactic  structure  or  semantic  dependencies.  After  identifying  the  portion  of  the 
code  which  is  of  interest,  programmers  use  Rational’s  Configuration  Manage¬ 
ment  and  Version  Control  (CMVC)  feature  to  check  out  individual  procedures  or 
entire  packages  for  development  or  modification.  This  allows  one  programmer 
exclusive  access  to  some  portion  of  the  software  and  thus  prevents  developers 
from  “stepping  on  one  another’s  toes.”  Rational’s  Ada-sensitive  editor  is  then 
used  to  enter  program  statements.  Ada  packages,  procedures,  functions,  loops, 
and  other  program  structures  are  automatically  closed  with  the  appropriate  end 
statements,  thus  minimizing  the  possibility  of  syntax  errors.  This  editor  also 
allows  customization  and  enforcement  of  site-specific  coding  standards. 

Periodically,  the  current  version  of  the  program  must  be  tested,  Ada  is  a 
strongly  typed  language,  and  it  checks  subprogram  calls  with  subprogram 
definitions  to  insure  argument  compatibility.  Furthemiore,  compilation  units 
(e.g.,  subprograms  and  packages)  may  import  other  packages  in  order  to  use  their 
type  and  variable  declarations,  and  such  imported  references  must  match  the  ori¬ 
ginal  declarations.  These  relationships  between  compilation  units  are  called 
dependencies  and  a  compilation  unit  which  accesses  or  uses  the  resources  of 
another  is  said  to  be  dependent  on  that  unit.  Obviously,  the  dependent  unit  must 
be  compiled  after  the  unit  on  which  it  depends.  In  large  Ada  soft\vare  systems  it 
is  common  for  what  seems  to  be  a  minor  modification  to  require  recompilation  of 
many  units  because  of  the  chain  of  dependencies.  If  such  systems  are 
sufficiently  large,  the  time  required  for  recompilation  becomes  the  bottleneck  in 
the  development  process.  The  Rational  Environment  avoids  this  problem 
through  intelligent  dependency  checking  and  incremental  compilation.  The 
former  feature  allows  the  Rational  to  avoid  recompilation  of  dependent  units  if  a 
modification  has  no  impact  (e.g.,  a  comment  was  added  or  changed).  After  this 
impact  analysis,  only  those  statements  which  are  dependent  are  recompiled. 

(This  statement  by  statement  compilation  is  possible  because  Ada  programs  are 
stored  using  the  Descriptive  Intermediate  Attributed  Notation  for  Ada  (DIANA) 
(Goos  et  al.  1983).  Ada  objects  (e.g.,  statements)  are  implemented  as  DIANA 
structures  that  represent  syntactic  stnicture  and  include  semantic  information  and 
executable  code.  This  is  much  different  from  the  conventional  approach  of 
source  code,  object  code,  and  executable  images  that  are  stored  in  separate  files,) 

When  a  version  of  the  software  is  required  for  the  actual  target  platform. 
Rational’s  Target  Build  Facility  allows  convenient  transfer  of  source  code  to  and 
compilation  on  a  particular  host.  Tliis  process  is  facilitated  by  the  Rational 
Compilation  Integrator,  which  permits  any  third-party  Ada  compiler  to  be 
integrated  with  and  managed  by  the  Rational  Environment.  This  tool  allows 
developers  to  build  software  for  multiple  platforms  (mainframe,  minicomputer, 
workstation,  personal  computer)  at  the  same  time.  With  the  Compilation 
Integrator,  only  those  portions  of  the  program  (individual  unit,  unit  closure,  sub¬ 
system,  or,  if  required,  entire  system)  are  (re)compiled.  Obviously  this  is  more 
efficient  than  compiling  tne  entire  system  prior  to  every  test. 

Periodically,  project  managers  and  team  leaders  require  information  about  the 
structure  and  status  of  the  system  under  development.  Rational  Insight™  per¬ 
forms  this  function  by  gathering  information  about  Ada  units  and  subsystems 
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from  the  integrated  information  repository  and  then  displaying  it  in  a  graphical 
fashion.  The  resulting  diagrams  show  dependencies  among  the  various  program 
structures  and  aid  in  understanding  the  relationships  among  the  software  com¬ 
ponents.  During  system  reengineering,  this  is  an  invaluable  capability. 

The  SEI  performed  an  evaluation  of  the  Rational  Environment  for  DoD 
(Feiler,  Dart,  and  Downey  1988).  This  study  assessed  its  functionality  in  the 
areas  of  system  installation,  system  administration,  detailed  design  and  coding 
functions,  testing  and  debugging,  compiler  quality,  configuration  management 
and  project  management  functions.  The  results  of  this  study  were  very  positive. 
THAMA,  WES,  and  CERL  have  jointly  conducted  their  own  evaluation  of  the 
Rational  Environment,  visithig  Rational’s  Washington  office  for  two  technical 
briefings  and  interviewing  Rational  users  at  four  sites  in  northern  Virginia. 
Impressions  from  these  visits  were  very  favorable.  Users  who  have  conducted 
their  own  studies  have  emphasized  that  no  other  development  environment 
approaches  the  Rational  in  functionality.  These  users  have  particularly  high 
praise  for  Rational’s  customer  assistance,  stressing  Rational’s  commitment  to  the 
success  of  the  customer’s  project.  There  are,  however,  a  few  disadvantages  to 
use  of  the  Rational.  It  is  quite  expensive;  an  entry  level  system,  including 
hardware  and  software,  costs  about  $250,000.  Fmdiciinore.  a  significant  amount 
of  training  is  required  to  take  full  advantage  of  this  sophisticated  environment’s 
capabilities.  In  spite  of  this  required  investment  in  hardware,  software,  and  per¬ 
sonnel,  the  Rational  Environment  is  capable  of  increasing  productivity,  lowering 
labor  costs,  and  adjusting  to  changes  in  requirements  or  target  platforms.  For  the 
foreseeable  future,  it  appears  to  be  the  best  way  to  effectively  develop  large  sys¬ 
tems  in  Aoa. 


Ada/Oracle  Interfaces 

The  Congressional  mandate  to  use  Ada  has  posed  some  significant  technical 
problems  for  those  involved  in  MIS  system  development.  Most  MIS  systems 
must  utilize  commercially  available  graphical  user  interfacec  '^GUls)  and/or  rela¬ 
tional  database  management  systems  (RDBMSs);  unfortunaieiy,  the  interfaces 
between  Ada  and  these  packages  have  traditionally  been  rather  poor,  This  prob¬ 
lem  is  compounded  by  the  lack  of  a  single  standard  in  each  of  these  areas.  For 
example,  a  program  written  for  the  MOTIF  GUI  is  not  portable  to  the  Open  Look 
GUI,  much  less  to  Microsoft  Windows,  and  an  application  which  accesses  the 
Xdb  RDBMS  generally  requires  modification  in  order  to  run  with  the  Oracle 
RDBMS.  The  NIST  has  recognized  these  problems  and  responded  with  an 
RDBMS  standard,  FIPSPUB  127-1  (NIST  1990  February),  and  a  GUI  standard, 
FIPSPUB  158  (NIST  1990  May).  Adherence  to  these  standards  by  both  software 
vendors  and  developers  will  make  development  of  portable  applications  in  Ada 
much  easier. 

The  reaction  of  many  software  DBMS  vendors,  including  Oracle,  to  the  adop¬ 
tion  of  Ada  and  the  development  of  standards  has  been  to  provide  bindings 
between  Ada  and  their  products.  There  are  currently  four  ways  to  construct  an 
Ada/RDBMS  interface:  (1)  proprietary  application  programmer  interface,  (2) 
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FIPS  127-1  compliant  embedded  SQL  precompiler,  (3)  FIPS  127-1  compliant 
module  language  compiler,  and  (4)  SQL-Ada  Module  Description  Language 
(SAMeDL)  compiler.  Because  the  first  method  is  neither  standard  nor  portable, 
it  does  not  satisfy  the  Government’s  needs.  The  last  technique  is  based  on 
research  at  Carnegie  Mellon  University.  It  is  still  in  an  embryonic  stage  with  no 
applicable  standards  and  no  available  commercial  implementations.  Neither  of 
these  techniques  will  be  discussed  here. 

The  second  method  is  currently  the  most  widely  used  method  of  binding  Ada 
programs  to  SQL-based  RDBMSs.  From  a  technical  perspective,  such  a  FIPS- 
compliant  Ada/SQL  binding  is  merely  a  way  of  allowing  SQL  statements  to  be 
embedded  in  an  Ada  program  so  that  the  program  may  exchange  information 
with  a  FIPS-compliant  RDBMS.  Prior  to  actual  compilation,  such  a  program  is 
first  processed  by  a  precompiler  which  translates  the  SQL  statements  into  Ada 
statements.  Oracle’s  implementation  of  this  method.  Pro*  Ada,  was  introduced  in 
1989  and  has  been  sold  to  over  300  sites  around  the  world.  It  is  available  on  a 
variety  of  platforms,  including  the  Corps’  Control  Data  CEAP  systems  as  well  as 
other  major  UNIX  platforms  (e.g.,  HP,  IBM,  SCO,  and  Sun).  Furthermore, 

Pro*  Ada  has  the  distinction  of  being  the  first  Ada/SQL  embedded  SQL  binding 
to  pass  the  NIST  test  for  ANSI  compliance.  It  has  since  passed  that  test  on  many 
different  platforms,  both  UNIX  and  non-UNIX.  Although  the  use  of  Pro* Ada 
adds  an  additional  step  to  the  process  of  program  testing,  it  actually  improves 
programmer  productivity  and  system  performance.  Moreover,  it  allows  dynamic 
construction  of  SQL  statements  at  runtime.  The  nature  of  these  benefits  will  be 
discussed  in  the  following  paragraph. 

Improved  programmer  productivity  is  a  result  of  Pro*Ada’s  extensive  syntac¬ 
tic  and  semantic  checking.  All  SQL  statements  are  validated  during  precompila¬ 
tion  so  that  errors  may  be  detected  and  corrected  before  the  potentially  time  con¬ 
suming  compilation  and  binding  of  the  Ada  prog.ram.  During  the  semantic 
checking  phase,  Pro*Ada  queries  the  database  to  first  determine  if  the  table  used 
in  the  SQL  statement  actually  exists,  and  then  to  see  if  the  table  has  a  column 
whose  name  matches  the  onv.  mentioned  in  the  statement.  These  features  save 
developers  from  performing  many  useless  compilations.  Increased  system  per¬ 
formance  results  from  use  of  Pro*  Ada’s  array  interface  (an  extension  to  the  FIPS 
standard).  Use  of  this  interface  allows  insertion  or  retrieval  of  batches  of  records 
with  a  single  database  call.  For  example,  an  EXEC  SQL  FETCH  may  fetch  up  to 
32K  records;  this  can  reduce  network  traffic  because  one  fetch  of  32K  records 
requires  fewer  packets  than  32K  fetches  of  single  records.  Finally,  Pro* Ada 
allows  dynamic  construction  of  SQL  statements  at  execution  time.  This  power¬ 
ful  capability  allows  construction  of  an  SQL  statement  within  a  program  variable 
and  submission  of  the  statement  to  the  RDBMS  while  the  program  is  running  (a 
feature  similar  ii,  spirit  to  FORTR.AN’s  object-time  FORMAT). 

The  third  method  is  the  newest  approved  standard  for  binding  Ada  programs 
to  SQL-based  RDBMSs;  it  differs  from  the  previous  approach  in  that  the  Ada 
program  and  the  SQL  procedures  (modules)  arc  stored  in  separate  files.  The 
SQL  file  is  translated  by  the  SQL*Module  compiler  into  Ada,  then  compiled,  and 
placed  in  an  Ada  library.  The  Ada  program  is  then  also  compiled  and  external 
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references  to  the  SQL  modules  are  satisfied  from  this  library.  Oracle’s  imple¬ 
mentation  of  this  technique,  SQL*Module,  was  announced  in  June  1992  and 
should  be  available  in  the  first  half  of  1993.  Prior  to  its  release  it  will  meet  the 
NIST  test  for  FIPS-compliant  module  language  compilers. 

The  first  benefit  of  using  this  third  technique  is  the  clean  separation  of  Ada 
and  SQL,  thus  improving  maintainability  and  allowing  developers  to  specialize 
in  Ada  or  SQL  without  having  to  learn  both.  It  also  allows  developers  to  use 
Ada-specific  tools  and  SQL-specific  tools  where  they  are  appropriate.  Addi¬ 
tional  productivity  is  obtained  through  the  use  of  stored  procedures.  Developers 
may  store  their  SQL*Module  procedures  in  a  database  and  access  them  from  an 
Ada  program,  thus  promoting  module  reuse. 

Finally,  another  technique  for  improving  productivity  is  the  use  of  fourth  gen¬ 
eration  languages  (4GLs),  This  involves  specification  of  an  application  in  a 
high-level  design  language  (the  4GL).  and  then  translation  of  this  program  to 
Ada.  Many  such  code  generators  are  available;  however,  the  vast  majority  of 
them  generate  package  specifications,  type  declarations,  and  procedure  calls,  but 
then  provide  only  procedure  stubs.  An  exception  to  this  is  the  Oracle  product 
GenerAda,  a  prototype  of  which  was  recently  demonstrated  at  TRl-Ada  ’92.  It 
creates  a  complete  application  in  Ada  which  is  compilable  and  executable. 

Early  in  1993,  WES  will  be  working  with  Oracle,  under  the  sponsorship  of 
THAMA,  to  test  and  evaluate  this  product  using  a  real  application. 


Code  Production  Environments 

Even  if  the  Corps  decides  to  obtain  one  or  more  Rational  systems,  they  will 
not  be  capable  of  supporting  a  large  number  of  developers.  Cost-effective  tools 
must  be  found  to  support  the  remaining  developers.  For  this  purpose  the  Corps 
requires  a  comprehensive  tool  set  containing  high-level  analysis  and  design  aids, 
a  code  production  environment,  a  database  interface,  a  test  generation  facility, 
software  metrics  collectors,  and  project  management  tools.  These  should  be 
seamlessly  integrated  with  an  intuitive  interface  and  be  available  on  a  variety  of 
platforms,  including  PCs,  RISC  workstations,  and  CD  4000  series  servers. 

Unfortunately,  such  an  environment  does  not  exist.  As  a  first  step  in  that 
direction,  the  Government  has  defined  an  Ada  Programming  Support  Environ¬ 
ment  (APSE)  to  assist  commercial  vendors  in  producing  comprehensive  software 
engineering  environments.  The  lowest  defined  level  is  called  a  Minimal  APSE 
(MAPSE)  and  consists  of  an  editor,  compiler,  library  management  system,  linker, 
and  run  time  environment.  Except  for  the  latter  two  items,  which  are  provided 
by  DOS,  this  MAPSE  tool  set  is  provided  with  the  Alsys  FirstAda  compiler  via  a 
menu-driven  interface  called  Adam.  Adam  is  actually  built  on  top  of  the  Alsys 
AdaWorld  command  line  environment  and  translates  menu  selections  to 
AdaWorld  commands.  In  addition  to  the  MAPSE  set,  other  features  accessible 
through  Adam  include  a  verifier  (fast  syntax  checker),  source  code  level 
debugger,  reformatter,  cross  referencer,  make  facility,  and  a  line  counting  metric 
collector.  Users  may  substitute  their  own  editor  for  the  Adam  default,  and  access 
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to  the  operating  system  and  the  AdaWorld  command  line  environment  is  pro¬ 
vided.  ^lovice  and  expert  modes  of  operation  are  available,  which  display  few  or 
many  menu  options,  respectively.  The  Adam  interface  takes  up  a  significant 
amount  of  memory,  Binding  a  moderately  sized  program  will  occasionally  fail 
due  to  lack  of  memory  for  symbol  tables;  this  may  be  remedied  by  switching  to 
the  command  line  environment,  Adaworld.  In  spite  of  this  minor  problem, 
experience  with  this  product  indicates  that  it  is  a  useful,  effective,  and  smoothly 
integrated  system  for  Ada  code  production  (Wheeler  1992). 

The  Ada  Workstation  Environment  (AWE),  marketed  by  AETECH,  is 
intended  to  provide  a  full  set  of  Ada  programming  tools.  Like  Adam,  it  is  built 
on  top  of  the  Alsys  AdaWorld  command  line  environment  running  under  DOS, 

Its  features  include  an  editor,  library  manager,  macro  generation  facility, 
compiler-binder  control  facility,  templates  for  types  and  program  units,  and  a 
menu  for  support  tools.  These  support  tools,  which  must  be  purchased 
separately,  include  an  on-line  Ada  reference  manual,  an  on-line  computer- 
assisted  instruction  system,  a  hypertext  Ada  reference  manual,  an  ASCII  table,  a 
border  graphics  drawing  tool,  tool  for  conversion  of  numbers  to  different  bases, 
and  tools  to  perform  top-down  structured  design,  object-oriented  design,  genera¬ 
tion  of  source  code  from  design,  and  generation  of  procedure  body  from  pro¬ 
cedure  specification.  The  basic  functions  work  very  well,  and  the  template  facil¬ 
ity,  not  available  in  Adam,  is  particularly  useful  in  making  skeletons  of  program 
units.  Most  common  tasks  have  a  convenient,  single  key  operation;  The  built-in 
editor  has  a  native  set  of  key  functions,  but  may  be  reconfigured  to  emulate  other 
editors.  The  primary  alternative  to  AWE  is  Adam,  and  Adam’s  biggest  advan¬ 
tage  is  that  it  is  bundled  with  the  Alsys  compiler.  However,  even  without  the 
additional  tools,  AWE  may  offer  enough  additional  functionality  to  be  con¬ 
sidered  as  an  alternative,  but  a  decision  regarding  its  adoption  should  be  delayed 
until  a  decision  is  made  on  whether  DOS  or  UNIX  is  to  be  the  ultimate  develop¬ 
ment  environment. 


Screen  Generators 

Screen  Machine,  marketed  by  Objective  Interface  Systems,  is  an  interactive 
package  that  provides  a  means  of  graphically  creating  panels  on  a  screen,  editing 
these  panels,  and  placing  fields  in  them  using  the  PanEdit  interface.  Panel  infor¬ 
mation  is  saved  in  a  database  and  the  source  code  to  create  these  panels  (two 
complete  Ada  packages)  is  generated  by  the  program  GenCode.  To  complete  the 
interface,  the  programmer  writes  the  application  software  to  manipulate  these 
screens  and  process  the  input  data  and  then  modifies  one  of  the  package  bodies 
to  handle  specific  input  selections. 

The  major  advantage  of  Screen  Machine  is  the  ease  of  producing  the  actual 
panel  creation  source  code.  The  user  has  only  to  enter  the  size,  location,  color, 
number  of  fields,  and  any  included  title  to  create  a  panel,  and  this  is  done  through 
an  interactive  screen.  Fields  can  easily  be  added  to  this  panel  to  form  a  database 
entry  screen  or  just  an  information  panel.  The  user  is  able  to  see  the  created 
panel  and  edit  it  without  having  to  write  or  compile  any  code.  After  the  user  is 
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satisfied  with  the  appearance  of  a  panel,  two  approaches  are  possible;  first,  the 
Ada  program  may  access  it  as  needed  from  a  disk  file,  or  second,  the  Ada  source 
code  to  create  the  panel  may  be  generated  and  then  incorporated  into  a  program. 
The  former  method  minimizes  program  size,  while  the  latter  maximizes  program 
execution  speed. 

A  major  disadvantage  of  the  S':^reen  Machine  is  its  documentation.  The  ver¬ 
sion  evaluated  for  the  Corps  was  documented  in  a  single  three  ring  binder  with 
chapters  dedicated  to  PanEdit,  GenCode,  and  the  package  libraries.  The  text  was 
readable  but  vague,  and  lacked  examples.  Furthermore,  the  index  has  not  been 
updated  to  reflect  changes  in  the  text  (Wheeler  1992).  Thus,  the  Screen  Machine 
is  a  good  tool  for  learning  the  process  of  screen  development  without  having  to 
actually  program  a  screen  from  scratch.  It  enables  the  user  to  see  the  screen  as  it 
is  being  created  and  allows  one  to  make  changes  without  repetitively  recompil¬ 
ing  and  relinking.  The  version  described  here  seemed  to  lack  the  functionality 
required  for  more  elaborate  I/O,  although  many  developers  at  the  Rational  user 
sites  visited  by  the  Corps  were  using  it  effectively  and  recommended  it  highly. 
This  apparent  difference  in  capability  may,  however,  be  due  to  the  Corps’s 
evaluation  of  Screen  Machine  on  a  PC  running  DOS,  while  the  Rational  sites 
were  using  it  on  RISC-based  workstations  running  UNIX  and  the  X  Window 
System. 

The  Textual  User  Interface  (TUI)  is  a  screen  development  tool  written 
entirely  in  Ada  and  marketed  by  AdaSoft,  Inc.  TUI  is  comprised  of  three  tools: 
AdaWindows,  which  contains  procedures  for  window  generation  and  control, 
AdaMenus,  which  deals  with  menus  of  various  types,  and  AdaFonns,  which 
deals  with  forms  for  input  and  output.  Documentation  for  each  package  is  pro¬ 
vided  separately  and  is  of  high  quality.  A  facility  is  provided  for  maintaining 
default  values  between  sessions  and  for  maintaining  a  history  of  all  data  entered. 
Some  screen  builders  are,  in  effect,  low  level  libraries  of  functions,  while  others, 
such  as  Screen  Machine  provide  a  much  higher  level  of  abstraction.  TUI  is  a 
compromise  lying  between  these  two  extremes.  It  is  composed  of  procedures 
and  functions,  but  at  an  intermediate  level  with  much  of  the  detail  still  hidden 
from  the  user.  TUI  includes  a  number  of  useful  features;  for  example,  when  an 
editor  is  needed  in  a  field,  it  is  present  by  default  and  does  not  have  to  be  expli¬ 
citly  invoked,  used,  and  then  exited.  AdaForms  handles  I/O  for  all  standard  Ada 
types  except  records  and  arrays,  strings  are  the  only  array  type  allowed.  In  addi¬ 
tion,  it  provides  a  List_Class,  for  selection  from  a  displayed  list,  and  a 
Text_Class,  for  I/O  of  multiple  lines  of  text.  Ada  type  checking  is  performed  on 
input  data  to  a  field  before  it  is  accepted.  The  TUI  is  a  well  designed,  logically 
structured,  flexible,  well  documented  set  of  components  for  screen  building  in 
Ada,  and  is  available  for  both  DO.S  and  UNIX  platforms  (Wheeler  1992). 
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Database  Managers 

Interfaces  between  Ada  and  DBMSs  will  be  important  to  the  Corps  for  the 
development  of  management  information  systems.  Possible  interfaces  to  Oracle 
have  already  been  discussed;  three  additional  possibilities  are  considered  here. 
The  first  is  AdaSAGE,  a  public  domain  database  generation  package  written  in 
Ada  that  produces  a  complete  system,  including  interface  screens.  The  second 
alternative  would  make  use  of  two  products  marketed  by  AdaSoft:  AdaManager, 
which  creates  and  manipulates  databases,  and  AdaQuest,  which  serves  as  an 
interactive  interface  to  AdaManager.  The  third  possibility  involves  construction 
of  an  Ada  “wrapper"  around  an  existing  DBMS  (dbVista  III)  using  the  Ada 
interface  pragma. 

AdaSAGE  is  a  public  domain  package  developed  and  maintained  by  the 
Idaho  National  Engineering  Laboratory  (INEL);  it  is  designed  to  facilitate  rapid 
development  of  Ada  systems.  A  descendant  of  the  SAGE  system  developed  in 
FORTRAN  by  INEL  about  10  years  ago,  AdaSAGE  is  the  result  of  work  on  the 
Marine  Corps  Combat  Readiness  Evaluation  System  (MCCRES).  INEL  pro¬ 
duced  a  prototype  of  MCCRES  in  Ada  for  the  Marine  Corps  in  Alsys  Ada  and  at 
the  same  time  converted  SAGE  to  Ada.  Primarily  suited  to  MIS  applications,  its 
capabilities  include  command  line  and  embedded  ANSI-compliant  SQL,  graph¬ 
ics,  communications,  formatted  windows,  on-line  help,  sorting,  editing,  and 
more.  AdaSAGE  applications  can  be  run  in  the  stand-alone  mode  or  in  a  mul¬ 
tiuser  environment.  One  of  the  most  powerful  features  of  AdaSAGE  is  the  Gen¬ 
eric  RApid  Prototyping  Language  (GRAPL).  Tliis  interpretive  language  allows 
complete  prototyping  of  a  database  application  that  can  be  executed  intetpreta- 
tiveiy  without  actual  compilation.  After  the  developer  is  satisfied  with  the  appli¬ 
cation,  it  is  relatively  easy  to  convert  it  to  Ada.  Using  AdaSAGE,  it  is  possible 
to  design  and  implement  an  application  in  a  minimum  of  time  that  performs  well 
and  is  easy  to  modify. 

All  four  Services  have  reported  significant  success  in  developing  applications 
with  AdaSAGE;  their  experience  has  shown  AdaSAGE  to  be  equally  applicable 
to  both  small  and  large  projects.  The  Government  considers  it  to  be  an 
extremely  valuable  tool  and  continues  to  fund  its  maintenance  and  enhancement. 
If  the  Corps  decides  to  use  AdaSAGE,  the  software  itself  is  free,  but  Corps  per¬ 
sonnel  should  attend  formal  AdaSAGE  training  provided  by  INEL,  and  one  indi¬ 
vidual  at  each  development  site  should  join  the  AdaSAGE  User’s  Group 
($1, 600/year).  As  a  member,  this  person  will  serve  as  the  organization’s  point  of 
contact  for  AdaSAGE  and  will  be  provided  with  the  following  services:  current 
versions  of  software  libraries  and  documentation,  technical  support  via  a  tele¬ 
phone  hot  line,  access  to  electronic  bulletin  board  services,  newsletter  subscrip¬ 
tion,  and  invitation  to  the  annual  meeting  held  in  Idaho  Falls, 

The  second  approach  is  the  use  of  AdaManager/ Adaquest.  AdaManager  pro¬ 
duces  a  relational  database  that  is  dynamically  structured  rather  than  built  on  a 
static  schema.  It  allows  the  logical  structure  of  the  data  to  be  changed,  and  addi¬ 
tional  columns  to  be  added  without  unloading  and  reloading  the  data.  It  is  possi¬ 
ble  to  insert,  delete,  update,  fetch,  select,  and  view  rows  as  well  as  join  and  save 
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tables,  and  re-order  rows  during  retrieval.  The  base  types  used  are  those  of  Ada 
except  that  strings  are  the  only  structured  types  allowed.  AdaQuest  is  an  interac¬ 
tive  interface  to  the  AdaManager  database  system.  It  is  a  stand-alone  tool  con¬ 
taining  32  commands  (procedures)  and  provides  either  menu  or  command  line 
access  to  all  of  the  functions  of  AdaManager.  It  is  particularly  valuable  for  con¬ 
structing  databases.  AdaQuest  can  be  used  to  define  databases,  tables,  types,  and 
columns,  as  well  as  performing  administrative  tasks.  Although  it  is  easy  to  use, 
it  does  require  a  knowledge  of  AdaManager.  Documentation  is  complete,  logi¬ 
cally  arranged,  and  clearly  written;  its  high  quality  is  consistent  with  that  sup¬ 
plied  with  other  AdaSoft  products  (Wheeler  1 992). 

The  final  database  interface  discussed  here  is  the  construction  of  an  interface 
between  Ada  and  the  dbVista  III  package  now  in  use  fro  PC-targeted,  THAMA- 
sponsored  software.  WES  has  developed  such  an  interface,  and  it  is  currently 
being  tested.  It  is  not  anticipated  that  dbVista  will  be  widely  used  with  Ada,  par¬ 
ticularly  for  developing  new  software,  but  the  interface  may  be  valuable  for  con¬ 
verting  some  existing  programs  to  Ada  when  such  software  is  being  substantially 
modified.  The  Ada  interface  modules  and  a  user  guide  are  available  from  WES. 


Analysis  and  Design  Aids 

Rational  Rose,  from  Rational,  is  a  graphical  CASE  tool  which  supports 
object-oriented  analysis  and  design.  It  is  available  on  IBM  RS/6000  and  Sun 
SPARC  workstations  as  a  stand  alone  product;  X  terminals  attached  to  those  sys¬ 
tems  may  also  access  Rose.  It  does  not  require  the  Rational  Environment.  It 
allows  developers  to  create  class  diagrams  which  serve  as  blueprints  of  high 
level  system  abstractions,  specify  class  attributes  which  provide  detailed  design 
information,  and  illustrate  the  design  through  object  diagrams  of  system  mechan¬ 
isms,  Rose  uses  the  Booch  notation  (Booch  1991);  it  enforces  the  notation’s  syn¬ 
tax  and  verifies  its  semantics  by  prohibiting  occurrences  of  multiple  inheritance, 
as  well  as  by  checking  for  class  visibility  and  multiple  class  relationships.  All  of 
the  underlying  information  is  represented  in  ASCII,  thus  it  allows  developers  to 
use  their  current  source  code  control  system  to  manage  versions  of  the  design 
just  as  they  manage  versions  of  the  code.  Rose  is  customizable  and  extensible; 
users  may  modify  menus  and  integrate  the  product  with  other  CASE  tools.  There 
are  several  possibilities  for  output:  printed  PostScript,  encapsulated  PostScript 
file,  or  FrameMaker-compatible  file.  A  floating  license  which  allows  a  single 
copy  of  Rose  to  be  shared  among  multiple  users  is  available  for  $3,995, 

Like  Rose,  Teamwork/ Ada  is  also  based  on  the  X  Window  System. 

Developed  by  Cadre  Technologies,  it  is  available  on  RISC  workstations,  includ¬ 
ing  those  from  DEC,  HP,  IBM,  and  Sun,  and  also  on  X  terminals  connected  to 
those  hosts.  The  centerpiece  of  this  product  is  the  Ada  Structure  Graph  (ASG) 
editor,  which  allows  developers  to  create,  view,  and  change  Ada  design  com¬ 
ponents  in  a  graphical  manner  using  the  Buhr  notation  (Buhr  1984).  Using  the 
ASG,  it  is  possible  to  display  a  diagram  in  several  windows,  thus  allowing 
detailed  editing  in  a  close-up  view  and  simultaneous  visualization  of  the  global 
impact  of  a  modification  in  a  high-level  view.  Teamwork/Ada  automates  the 
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transition  from  design  to  implementation  through  integration  with  Cadre’s  Ada 
Source  Builder  (ASB)  and  Design  Sensitive  Editor  (DSE).  When  used  with  the 
ASG,  these  two  tools  enforce  consistency  between  the  design  and  the  coded 
implementation,  prohibiting  changes  that  would  make  the  design  obsolete.  The 
ASB  analyzes  the  output  of  the  ASG  and  produces  Ada  code  which  corresponds 
to  the  design  and  contains  “code  frames.”  Implementation  details  may  then  be 
inserted  into  the  generated  code  using  the  DSE,  but  only  within  the  code  frames. 
The  DSE  automatically  detects  Ada  syntax  errors,  and  may  be  configured  to 
emulate  other  editors  and  to  enforce  site-specific  coding  standards.  Existing  Ada 
code  may  be  processed  using  the  ASG  Builder  which  creates  ASGs  from  source 
code  in  order  to  facilitate  reuse,  reengineering,  and  maintenance.  Information 
produced  during  this  design  process  is  saved  in  a  project  database  and  may  then 
be  accessed  by  the  Document  Production  Interface,  Teamwork/DPI,  to  produce 
documentation  compliant  with  DoD-STD-2167A.  Teamwork/ Ada  is  part  of 
Cadre’s  Teamwork  environment  which  includes  facilities  for  simulation  of 
software  systems,  constmction  of  real-time  systems,  modeling  of  information, 
and  communication  with  widely-used  DBMSs  (e.g.,  Ingres,  Oracle,  and  Sybase). 
If  the  Corps  decides  to  use  the  Rational  Environment,  Teamwork’s  interface  to 
that  system  would  make  it  a  powerful  addition  to  the  coding  environment.  If  the 
Corps  decides  against  Rational,  Teamwork,  along  with  an  appropriate  compila¬ 
tion  system,  is  surely  one  of  the  top  contenders  for  an  integrated  development 
environment. 


Metrics  Collectors 

An  important  aspect  of  the  development  process  is  quality  control.  Unless 
data  is  obtained  to  measure  program  quality,  this  will  be  difficult,  if  not  impossi¬ 
ble.  One  such  tool  for  gathering  these  data  is  AdaMAT,  from  Dynamics 
Research  Corporation.  This  is  a  static  source  code  analyzer  which  uses 
DlANA-based  metrics  to  measure  management  concerns  such  as  reliability,  por¬ 
tability,  and  maintainability,  as  well  as  software  engineering  concerns  such  as 
code  simplicity,  modularity,  self-descriptiveness,  clarity,  and  independence. 
These  scores  are  calculated  by  calculating  the  ratio  between  the  number  of 
adherences  to  a  particular  guideline  and  the  total  number  of  adherences  and 
nonadherences.  AdaMAT  is  useful  in  many  activities  throughout  a  project, 
including  design  assessment,  code  walk  throughs,  error  prevention  and 
discovery,  system  installation  and  checkout,  and  maintenance. 


How  to  Proceed 

The  use  of  Ada  offers  many  advantages  over  other  languages.  Many  of  its 
features  were  specifically  intended  to  support  good  software  engineering  prac¬ 
tice;  examples  include  its  library  consistency  requirement  its  extremely  thorough 
compile  time  checking.  Its  technical  advantages  are  clearly  seen  and  other 
languages,  e.g..  Turbo  Pascal,  Modula-2,  and  C-i-i-,  have  attempted  to  incorporate 
at  least  some  of  its  features.  Since  Ada  is  more  advanced  than  many  other 
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language  systems,  it  requires  a  higher  level  of  sophistication  for  optimum  use.  It 
must  be  systematically  introduced  or  chaos  can  result. 

A  well  conceived  plan  should  be  followed  which  will  promote  a  smooth  tran¬ 
sition  to  Ada  without  false  starts  and  wasted  effort.  The  following  paragraphs 
propose  an  outline  of  this  plan.  Throughout  the  transition,  the  key  to  success 
will  lie  in  the  education  of  the  personnel  involved.  Management  must  recognize 
that  several  years  will  elapse  before  development  staff  acquire  the  expertise  and 
fully  adopt  the  techniques  that  will  produce  the  dramatic  cost  savings  advertised 
by  various  Ada  proponents.  Development  staff  members  must  realize  that  formal 
training  is  only  the  first  step  in  their  personal  transition  to  Ada,  and  that  they 
must  understand  and  then  put  into  practice  not  just  new  programming  language 
syntax,  but  a  new  development  philosophy  as  well.  Furthermore,  project  spon¬ 
sors  must  understand  that  software  engineering  is  engineering.  If  they  were 
sponsoring  a  civil  works  project,  such  as  the  co.nstruction  of  a  suspension  bridge, 
they  would  not  show  up  at  the  site  a  month  after  project  initiation  and  ask  what 
percent  of  the  bridge  has  been  completed  or  ask  for  a  prototype  bridge  to  drive 
over  in  order  to  determine  its  “look  and  feel.”  They  must  understand  that  the 
new  development  process  to  be  instituted  as  part  of  this  transition  will  involve 
more  initial  planning  and  less  time  spent  coding  and  that  the  result  will  be  a  pro¬ 
duct  which  is  more  reliable  and  easier  to  maintain.  Finally,  everyone  should 
realize  that  some  aspects  of  the  transition  will  be  perpetual,  Specifically,  pro¬ 
cedures  and  techniques  must  periodically  evaluated  and  if  they  have  proven 
ineffective,  or  if  new  technology  has  rendered  them  obsolete,  then  they  must  be 
changed. 

It  is  imperative  that  several  steps  be  immediately  taken  to  begin  the  transition 
to  use  of  Ada.  If  they  are  not,  the  first  several  projects  implemented  in  Ada  will 
be  delayed  while  developers  acquire  expertise  in  the  Ada  language,  object- 
oriented  design,  and  software  engineering  methods  and  tools.  These  near-term 
actions,  to  be  completed  during  the  first  year  of  the  transition,  include: 

•  Acquisition  of  Ada  compilers.  Alsys  FirstAda  seems  to  be  a  good  first  choice 
for  PC  platforms,  although  if  an  interface  to  Microsoft  Windows  is  necessary, 
the  Meridian  product  should  be  considered,  as  well.  The  Verdix  compiler 
should  be  viewed  as  a  strong  contender  for  RISC-based  workstations, 

•  Acquisition  of  an  APSE  for  PC  platforms.  The  selection  of  this  environment 
will  depend  on  the  hardware/OS/compiler  combination  under  consideration. 
For  80X86/DOS/Alsys,  the  Adam  interface  bundled  with  the  Alsys  compiler 
is  a  reasonable,  cost-effective  choice.  For  RISC-based  workstations  running 
UNIX,  the  situation  is  similar  in  that  a  high-quality  APSE  is  available  from 
the  compiler  vendor;  this  is  particularly  true  of  the  Verdix  compiler  and  its 
associated  VADSpro  programming  environment. 

•  Initiation  of  an  Ada  training  sequence.  Many  training  vendors,  e.g.,  EVB, 
Fastrak  Training,  and  Texel,  have  courses  that  cover  the  topics  listed  earlier. 
One  should  be  selected  and  an  initial  group  should  begin  a  formal  training 
sequence. 
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•  Selection  of  potential  Ada  experts.  These  individuals  should  immediately  be 
assigned  the  tasks  noted  earlier,  specifically  those  associated  with  reviewing 
current  Ada  technology  and  with  assisting  other  developers  in  making  the 
transition. 

•  Acquisition  of  Ada  reference  materials.  These  include  the  serials  noted  pre¬ 
viously  as  well  as  items  from  the  bibliography. 

•  Adoption  of  software  engineering  methodology  as  standard  practice.  This 
includes,  among  other  things,  development  of  formal  design  specifications, 
application  of  object-oriented  design  techniques,  adoption  of  and  adherence 
to  an  Ada  style  guide,  code  walkthroughs,  thorough  testing,  and  collection  of 
software  and  productivity  metrics  for  individuals  as  well  as  for  the  group  as  a 
whole. 

•  Decide  whether  or  not  to  obtain  the  Rational  Environment.  This  is  an  impor¬ 
tant  initial  decision  on  wiiich  many  future  decisions  will  depend,  including 
selection  of  hardware,  compilers,  and  CASE  tools.  Furthermore,  if  the  deci¬ 
sion  is  positive,  then  time  must  be  allowed  to  train  personnel  in  the  use  of  the 
system. 

Other  tasks  are  equally  important  but  need  not  be  accomplished  right  away; 

work  on  them  should  begin  during  the  first  year  of  the  transition  and  be  com¬ 
pleted  by  the  end  of  the  second.  Note,  however,  that  some  of  them  are  ongoing 

activities. 

•  Continuous  investigation  of  available  Ada  technology.  All  of  the  areas  dis¬ 
cussed  in  this  report  require  constant  monitoring.  Knowledge  of  advances  in 
software  engineering  methodologies,  CASE  tools,  and  object-oriented  tech¬ 
nology,  progress  at  Government  laboratories,  and  status  of  other  large-scale 
Ada  projects  will  all  be  useful  in  current  development  efforts, 

•  Adoption  of  a  reuse  policy.  The  Ada  experts  noted  above  must  investigate 
existing  Government  software  repositories  to  determine  what  components 
will  be  useful  to  current  projects.  A  local  reuse  library  must  be  established. 

•  Acquire  one  or  more  RISC-based  UNIX  workstations.  These  platforms  sup¬ 
port  better  CASE  tools  and  provide  a  development  environment  with  more 
functionality.  Appropriate  tools  should  be  purchased  simultaneously,  e.g.. 
Cadre’s  Teamwork,  HP’s  SoftBench,  IDE’s  Software  Through  Pictures,  and 
Rational  Rose.  These  should  be  tested  on  a  small  project  in  a  prototype 
fashion  and  the  most  promising  product  employed  on  subsequent  projects. 

•  Encourage  employees  to  stay  current  in  the  field.  As  part  of  their  Job  assign¬ 
ment,  employees  should  periodically  review  books,  Journal  articles,  case  stu¬ 
dies,  or  products  and  prepare  a  review;  this  could  then  be  shared  with  the  rest 
of  the  staff  in  a  short  one-hour  presentation.  If  this  were  scheduled  once  a 
month,  perhaps  as  a  brown-bag  luricheon/seminar,  then  it  would  not  be  bur¬ 
densome  to  the  presenter  or  the  staff. 
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•  Review  progress  in  making  the  transition.  This  involves  evaluation  of  all  of 
the  short-term  steps  noted  above  and  making  any  necessary  mid-course 
corrections.  Specifically,  attention  should  be  paid  to  modification  of  estimat¬ 
ing  models  based  on  experience  with  Ada  to  date,  evaluation  and  possible 
revision  of  the  training  program,  review  and  enhancement  of  software 
engineering  techniques  and  tools,  and  updating  library  holdings  on  Ada  and 
software  engineering, 

•  Make  plans  for  future  efforts.  Plans  should  be  made  to  address  the  following 
issues:  use  of  code  generators,  applications  of  artificial  intelligence  in  the 
project’s  functional  domain,  and  the  transition  to  Ada  9X. 

•  Plan  to  participate  in  an  SEI  Software  Process  Assessment.  This  accredita¬ 
tion  procedure  evaluates  an  organization’s  state  of  software  development 
practice  based  on  the  SEI  Capability  Maturity  Model.  This  scale  of  this 
model’s  evaluation  ranges  from  1,  which  describes  an  ad  hoc,  chaotic  situa¬ 
tion  to  5,  which  describes  a  software  development  approach  that  is  repeat- 
able,  defined,  managed,  and  optimizing.  This  is  possibly  the  most  important 
of  all  the  recomi  lendations. 

The  man  I"'  tte  to  use  Ada  should  be  viewed  as  an  opportunity  for  the  Corps  to 
assume  a  leadership  role  within  the  Army  in  the  area  of  software  development. 
The  Corps  of  Engineers  has  a  long  history  of  engineering  many  things  well,  and 
there  is  no  reason  why  the  Corps  should  not  engineer  software  well,  too.  Hope¬ 
fully  this  report  has  provided  initial  guidance  which  will  help  make  that  goal  a 
reality. 
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Appendix  A 
DoD  Directive  3405.1 


This  appendix  contains  the  text  of  DoD  Directive  3405.1  issued  on  April  2, 
1987  which  specifies  computer  programming  language  policy  for  the  DoD. 


Appendix  A  DoD  Directive  3405.1 


A1 


Dcpartmant  of  Do f ana* 

DXKJCCTXVE 

April  2,  1987 
NUMBER  3405.1 

ASD(C; 

SUBJECT t  Conputar  Prograamino  Languaga  Policy 

Rafaranoaa:  (a)  DoD  Xnstruation  5000.31,  "Xntarliu  Liat  of  DoD  Approvad  Higher 

Order  Programming  lianguagaa  (HOli),*  November  24,1976 
(hereby  aanaelad) 

(b)  DoD  Dlreativa  7740.1,  *DoD  Information  Reaouroea  Management 
Program,"  June  20,  1983 

(c)  DoD  Dlreativa  5000.1,  "Major  Syatem  Aoqulaitiona, "  March  12, 
1986 

(d)  DoD  Dlreativa  5000.29,  "Management  of  Computer  Paaouroea  in 
Major  Defenaa  Syatama,"  April  26,  1976 

( a )  through  ( J ) ,  aee  analoaure  1 

A.  PURPOSE 

Thla  Dlreativa  auperaedaa  refarenae  (a)  and  aupporta  referanoaa  (b)  and 
(a)  by  eatabliahlng  policy  for  computer  programming  languagea  uaed  for  the 
development  and  aupport  of  all  DoD  aoftware. 

B.  APPLICABILITY  AND  SCOPE 
Thia  Dlreativa i 

1.  Appliea  to  the  Office  of  the  Secretary  of  Defenaa  (OSD),  the  Military 
Departmenta  (including  the  Natioiuil  Guard  and  Reaerve),  the  Organization  of 
the  Joint  Chiefa  of  Staff  (OJCS),  the  Unified  and  Specified  Commanda,  the 
Xnapector  Oenaral  of  the  Department  of  Defenaa  (XO,  DoD),  the  Defenaa 
Agenclaa,  and  nonappropriatad  fund  aotlvitiea  (hereafter  referred  to 
collectively  aa  "DoD  Componenta" ) . 

2.  Covara  all  computer  raaourcea  managed  under  reference  (d)  or  OoD 
Dlreativa  7920.1  (reference  (a)). 

3.  Need  not  be  applied  retroactively  to  ayatema  that  have  entered 
full-acale  development  or  have  paaaed  Nlleatone  XX  of  rafarencea  (c)  and  (a), 
and  for  which  a  documented  language  commitment  waa  made  in  compliance  with 
pravloua  policy. 

C.  DEFINITIONS 

Special  terma  ujad  in  thia  Directive  are  explained  in  encloaura  2; 
otherwlae,  refer  to  the  "American  National  Dictionary  for  Information 
Procaaaing  Syatama"  (reference  (f)). 

D.  POLICY 

It  ia  DoD  policy  toi 

1.  Satiafy  functional  requiramante,  enhance  miaaion  performance,  and 
provide  operational  aupport  through  the  uae  of  modern  aoftware  ooncepta. 
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advmna^i  »oftwar«  taahaolos/y,  ■oftwara  lifa-oyola  aupport  tool*,  and  standard 
programoing  languagaa . 

2.  Aahlava  Inprovamanta  in  DoQ  aoftwaro  managauant  through  tha 
implamantatlon  o£  proaaaaaa  Cor  control  of  tha  usa  of  hlghar  ordar  languagaa, 
including  spaoif ioation  of  atandarda  and  waivar  procaduraa. 

3.  Limit  tha  numbar  of  programming  languagaa  uaad  within  tha  Dapartmant 
of  Dafanaa  to  faoilitata  achiavamant  of  tha  goal  of  tranaition  to  tha  uaa  of 
Ada*  (rafarsnoa  (g) )  for  DoD  aoftwara  davalopmant. 

a.  Tha  Ada  programming  languaga  ahall  ba  tha  aingla,  common,  oomputar 
prograxaming  languaga  fc.'  Dafanaa  oomputar  raaouroaa  uaad  in  intalliganca 
ayatama,  for  tha  oommand  and  control  of  tailitary  forcaa,  or  aa  an  intagral  part 
of  a  waapon  ayatam.  Programming  languagaa  othar  than  Ada  that  wara  authorizad 
and  baing  uaad  in  full-acala  davalopmant  may  continua  to  ba  uaad  through 
daploymant  and  for  aoftwara  maintananaa,  but  not  for  major  aoftwara  upgradaa. 

b.  Ada  ahall  ba  uaad  fur  all  othar  applicationa,  axcapt  whan  tha  uaa 
of  anothar  approvad  highar  ordar  languaga  ia  mora  ooat-af faotiva  ovar  tha 
application' a  lifa-cycla,  in  kaaping  with  tha  long-ranga  goal  of  aatabliahing 
Ada  aa  tha  primary  DoD  highar  ordar  languaga  (KOL) . 

c.  Vlhan  Ada  ia  not  uaad,  only  tha  othar  atandard  highar  ordar  pro¬ 
gramming  languagaa  ahown  in  ancloaura  3  ahall  ba  uaad  to  maat  ouatom-davalopad 
procadural  languaga  programming  raguiramanta .  Tho  uaa  of  apocific  KOL'a  ahall 
ba  baaad  on  capabilitiaa  of  tha  languaga  to  maat  ayatam  racpxiramanta ,  Ouidanoa 
in  aalacting  tha  appropriata  HOL  to  uaa  ia  providad  in  IIBS  Spacial  Publication 
500-117  (rafaranca  (h) ) . 

4.  Prafar,  baaad  on  an  analyaia  of  tha  lifa-oycla  coata  and  impact,  uaa 

of  t 


a.  of f-tha-ahalf  application  packagaa  and  advanoad  aoftwara  taolwology. 

b.  Ada ‘baaad  aoftwara  and  toola. 

c.  Approvad  atandard  HOL' a. 

5.  Conaidar  tha  potantial  impact  on  oompatition  for  futura  aoftwara 
and/or  hardwara  anhanoamanta  or  raplaoamant  whan  aalacting  Dafanaa,  public 
domain,  or  commaroially  availabla  aoftwara  packagaa,  or  advanoad  aoftwara 
tachnology . 

6.  Uaa  lifa-oyolo  managamant  praotioaa,  aa  raquirad  by  DoD  Diraotiva 
7920.1  (rafaranca  (a))  and  DoD  Diraotiva  5000.29  (rafaranca  (d)),  for  tha 
davalopmant,  aupport,  and  uaa  of  aoftwara,  whathar  ouatom-davalopad  or 
commaroially  acguirad. 

7 .  Raduoa  aoftwara  obaolaaoanca  and  tha  ooat  of  aoftwara  maintananca 
through  uaa  of  approvad  programming  languagaa  and  appropriata  advanoad 
aoftwara  tachnology  during  all  phaaaa  of  tha  aoftwara  lifa-oycla. 

E.  RESPONSIBILITIES 

1.  Tha  Aaaiatant  Sacratary  of  Dafanaa  (Comptrollar )  (ASD(C))  and  tha 
Undar  Sacratary  of  Dafanaa  (Acguiaitlon)  (USD(A))  ahall  jointly t 
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a.  Snaur*  that  tha  policy  and  prooaduraa  In  thla  Dlractlva  ara 
inplamantad . 

b.  Aaalgn  rasponslbllity  to  a  apaclflc  DoD  Conponant  to  act  aa  tha  DoD 
languapa-oontrol  apant  for  aach  DoD-approvad  atandard  HOL. 

c.  Procasa  nomlnationa  for  changaa  to  tha  Hat  of  approved  HOL' a. 

2.  Tha  Aaaiataut  Sacratary  of  Dafanaa  (Coaptrollar )  ahall: 

a<  For  automated  information  ayatama,  aatabliah  programa,  aa 
appropriate,  for  tha  anhanaamant  of  tha  aoftwara  anginaoring  procaaa  and  tha 
tranaltlon  of  auch  technology  from  tha  markatplaca  and  raaearoh  programs  to 
application  within  general  purpoaa  automated  data  prooaaaing  ayatama . 

b.  !>afine  raaaarch  and  development  raguiramanta  for  automated 
information  ayatama  after  oonaultatlon  with  DoS  Componanta  and  provide  auch 
roQ[uiramsntB  to  USD (A)  for  inclusion  in  their  raaaarch  and  development  program. 

3.  Tha  Under  Secretary  of  Dafanaa  (Aoguialtlon)  ahall: 

a.  Eatabliah  and  aupport  a  aoftwara  and  information  technology 
raaaarch  and  davalopmant  program  that  la  raaponslve  to  tha  idantlflad  needs. 

b.  Manage  tha  DoD  Ada  program  and  maintain  and  Ada  Joint  Program 
Office  (AJPO)  to  oversea  tha  maintananoa  of  the  Ada  language  and  tha 
inaartlon  of  Ada-ralatad  technology  into  tha  Dapartmant  of  Defense. 

o.  Eatabliah  raaaarch  programs,  aa  appropriate,  for  tha  anhanoamant 
of  software  anglnaaring  technology  and  transferring  such  technology  to  use  in 
intalliganc«  ayatama  and  ayatama  for  tha  command  and  control  of  military 
forcoa,  and  to  computer  raaourcca  that  ara  an  integral  part  of  a  weapon  system. 

4 .  The  Head  of  Each  DoD  Component  shall i 

a.  Implement  and  execute  internal  procedures  consistent  with  tha 
policy  and  procedures  in  this  Directive. 

b.  Designate  a  language-control  agent  for  each  approved  HOL  for  which 
tha  DoD  Component  is  assigned  responsibility  and  ensure  compliance  with  the 
procedures  in  enclosure  4. 

c.  institute  a  process  for  granting  waivers  to  the  use  of  approved 
HOL's  in  accordance  with  section  r.,  below. 

d.  Specifically  address  in  tha  Component's  overall  computer  resources 
planning  process : 

(1)  The  use  of  appropriate  advanced  software  technology  for 
developing  new  applications  and  technological  upgrades  of  existing  systems. 

(2)  The  current  use  of  assembly  languages,  nonstandard  HOL's, 
vendor  extensions,  and  enhancements  of  standard  HOL's,  and  actions  taken  to 
ensure  that  such  use  is  minimized. 

e.  Establish  a  program  for  evaluating,  prototyping,  and  inserting 
advanced  software  technology  into  the  development,  modification,  and 
maintenance  process,  and  hold  operational  software  managers  accountable  for 
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InvMstiMnt  in  mlsrratlon  to  advanoad  softwara  taohnology  for  thalx 
particular  anvlronuant . 


f.  Eatabliah  and  maintain  training,  aducatlon,  and  oaraar  davalopmant 
programs  that  will  anaura  that  SoD  parsonnal  ara  fully  abla  to  use  new 
advanoad  software  taobnologias . 

F.  WAIVER  PROCEDURES 

1.  Waivers  to  tha  policy  In  subsaotlon  D.3.,  above,  shall  bo  strictly 
controlled  and  closely  ravlawad.  Authority  for  issuing  waivers  is  delegated 
to  each  l^oD  Component. 

a.  Bach  proposed  waiver  shall  contain  full  justification  and  shall, 
at  a  minimum,  include  a  lifa-oycle  coat  analysis  and  a  risk  analysis  that 
addresses  technical  performance  and  schedule  impact.  Each  waiver  granted  by 
the  DoD  Component  shall  apply  to  only  one  system  or  subsystem. 

b.  Justification  for  granted  waivers  shall  be  provided  to  USD (A)  or 
ASD(C)  within  the  scope  of  their  individual  responsibilities,  as  periodically 
requested  for  review. 

2.  A  waiver  WEED  MOT  be  obtained  for  use  oft 

a.  Commercially  available  off-the-shelf  applioations  software  that  is 
not  modified  or  maintained  by  the  Department  of  Defense. 

b.  Commercially  available  off-the-shelf  advanced  software  technology 
that  is  not  modified  or  maintained  by  the  Department  of  Defense. 

c.  Computer  programming  languages  required  to  implement 
vendor-provided  updates  to  commercially  supplied  off-the-shelf  software.  Use 
of  such  languages  shall  be  restricted  to  implementing  the  vendor  updates. 

3.  A  waiver  XS  required  for  use  of  unmodified  Defense  or  public  domain 
software  that  does  not  conform  to  the  language  requirements  of  subsection 
D.3.,  above.  Haintenance  of  the  software  shall  be  specifically  addressed  in 
the  waiver  request  to  Include  life-oycle  maintenance  costs  and  the 
availability  of  source  codes  and  necessary  software  tools. 

0.  EFFECTIVE  DATE  AMD  IMPLEMENTATION 

This  Directive  is  effective  immediately.  Forward  one  copy  of  implementing 
documents  to  the  Assistant  Secrabary  of  Defease  (Cosiptroller )  and  one  copy  to 
tha  Under  Secretary  of  Defense  (Acquisition)  within  120  days. 

William  H.  Taft,  XV 
Deputy  Secretary  of  Defense 


Enclosures  -  4 

1.  References 

2.  Spsoial  Terms  and  Definltlona 

3 .  DoD-Approvad  Highar  Ordar  Prograioming  Languagaa 

4.  Procedures  for  Controlling  Higher  Order  Languages  (HOL) 


Appendix  A  DoD  Directive  3405.1 


A5 


*X&m  ia  a  Raffiatarad  Tradamark  of  tha  U.S.  Oovammant  (Ada  Joint  Projram 
Of f ioa) . 
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RBFERXNCSS,  continued 


(•)  DoD  Directive  7920.1,  "Life  Cycle  Henagement  of  Autonuited  Infonaatioti 
Syetema  (AIS),*  October  17,  1978 

(f)  Hational  Bureau  of  Standarda  (NBS)  FIPS  Publication  11-2,  "American 
National  Dictionary  for  Information  Proceeaing  Syatema,"  Hay  9,  1963 
(a)  ANSI/HIL-STD-1B15A-1983,  "Ada  Prograaming  Language,"  February  19B3 

(h)  National  Bureau  of  Standarda  Speolal  Publication  500-117,  "Selection  and 
Uaa  of  Oeneral  Purpoae  Programming  Languagea,"  October  1984 

(i)  DoD  4120. 3-M,  "Defence  Standardisation  and  Specification  Program  Policies 
Procedures  and  Instructions,"  August  197B,  authorised  by  DoD  Directive 
4120.3,  February  10,  1979 

(j)  DoD  Directive  5010.19,  "Conf igura^.ion  Management,"  Hay  1,  1979 
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SPECIAL  TZRUS  AND  DEFINITIONS 


1.  Advasaad  Softvrara  Taobnology.  Softwara  toola,  llfa-cycla  aupport  anviron~ 
aanta  (Inaludlnp  program  support  anvlroxuaants) ,  nonprooadural  languagas, 
modam  data  basa  managamant  aystauis,  and  othar  taohnologlas  that  provlda 
improvauants  in  productivity,  usability,  maintainability,  portability,  ate., 
ovar  tbosa  oapabilitiaa  oniwnonly  in  uaa. 

2.  Automatad  information  Syatama.  A  aollaotion  of  functional  usar  and 
automatic  data  procassing  paraonnal,  procaduras,  and  aguipmant  (including 
automatic  data  procassing  agulpmant (AOPE) )  that  is  dasignad,  built,  oparatad, 
and  maintainad  to  collact,  racord,  procass,  stora,  r.atrlava,  and  display 
Information. 

3.  Major  Softwara  Upgrada.  Radasign  or  addition  of  more  than  ona-thlrd  of 
tha  softwara. 
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OoD-Approvad  Highar  Ordar  Pcogranmlng  Languagaa 


Languaga 


Standard  Nuahar 


DoS  Control  Agant 


Induatry 

Control 

Agant 


Ada 


C/ATLAS 


COBOL 


0(£I-3M 


cus-2y 


FORTRAN 


JOVIAL  (J73) 


Ulnlmal 

BASIC 


PASCAL 


AMS2/HZL-STD-1815A-19e3 
(FIPS  119) 


ZBEE  STS  716-1985 


ANSI  X3. 23-1985  (FIPS  21-2) 


NAVSBA  0967LP-S9e-2210-19a2 


NAVSCA  Manual  M-5069,  M-5045 
M-5064-1981 


ANSI  X3. 9-1978  (FIPS  (.9-1) 


HZL-STD-1589C  (USAF) 


ANSI  X3. 60-1978  (FIPS  68-1) 


ANSI/IECX  770X3.97-1983 
(FIPS  109) 


Ada  Joint  Program! 
OCfloa  I 


Navy 


Air  Foroa 


Navy 


Navy 


Air  Farco 


Air  Faroe 


Air  Force 


Air  Foroa 


ANSI 


IEEE 


ANSI 


N/A 


N/A 


ANSI 


N/A 


ANSI 


ANSI 


SPL/1 


SPL/1  Language  Rafaranoa 
Manual.  Zatamatrloa  Report 
No.  172-1 


Navy 


N/A 


Note.  Sea  NBS  Special  Publioation  500-117  (rafaranoa  (h) ) . 
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PROCEDUSCS  FOR  CONTROLIilEia  HIQKZR  ORDER  LANSUAGES  (HOL) 


1.  All  Ada  conpllara  that  ara  uaad  for  craation  of  aoftwara  to  ba 
dallvarad  to  or  nalntainad  by  tba  Oovanunant  ahall  ba  formally  valldatad  In. 
aocordanca  with  prooaduraa  and  guldallnaa  aat  by  tha  AJFO. 

2.  Each  DOD-approvad  HOL  ahall  ba  aaalpnad  to  a  DoD  languaga-control 
agant,  aa  ahoivna  In  ancloaura  3,  who  shall: 

a.  Hava  tha  authority  and  raaponaibility  for  propar  aupport  of  all 
languaga-control  aotivitiaa  naadad  to  provida  for  naoaasary  modification  and 
inprovamant  of  tha  aaaignad  HOL.  Tha  agant  shall  oparata  in  accordanca  with 
DoD  4120. 3-H  (rafaranoa  (i) ) . 

b.  Provida  configuration  control  for  DoD  KOL'c  In  accordanca  with 
DoL  Diractiva  5010.19  (rafaranoa  (dl).  For  HOL's  controllod  undar  industry 
(a.g.,  lastituta  for  Elaotrioal  and  Elactronio  Enginaars  or  Amarioan  National 
Standards  Xnstituta)  prooaduras,  tha  agant  ahall  raprasant  tha  Dapartmant  of 
Dafansa  to  tha  controlling  body. 

c.  Maintain  a  singla  standard  dafinition  of  tha  aasignad  HOL  and  maha 
this  dafinition  documant  availabla  aa  a  Fadaral,  DoD,  military,  or  adoptad 
industry  standard.  Tha  agant  shall  also  gathar  and  dissaminata  appropriate 
information  ragarding  usa  of  tha  HUL,  its  coupilars,  intarpratars,  and 
aasociatad  tools. 

3 ■  A  DoD  Component  nay  nominate  a  language  for  removal  from  the  list 
of  approved  languages  by  s\ihmitting  a  justification  documant,  which  presents 
the  ratioiiala  for  tha  proposed  halation  and  an  impact  analysis,  to  tha 
ASD(C),  vlao  will  coordinate  it  with  USD(A). 

4.  A  DoD  Component  may  also  nominate  a  language  for  inclusion  on  the 
list  of  approved  languages  by  submitting  a  justification  documant  to  the 
ASD(C),  who  will  coordinate  it  with  USD(A) .  Tha  justification  documant 
shall  include  tba  following: 

a.  A  detailed  rationale  for  using  tba  language,  including  how  tha 
candidate  language  meats  specific  DoD  requirements  that  are  not  satisfied  by 
the  approved  languages . 

b.  A  description  of  tba  language  and  the  environment  and  a  detailed 
unambiguous  specification  of  tha  language. 

c.  An  economic  analysis  of  the  impact  of  tha  language  over  its 
expected  lifa-cycla. 

d.  A  detailed  plan  for  implementing  and  supporting  tha  language, 
including  identification  of  tba  DoD  Component  that  will  accept  designation  as 
control  agant  for  tha  language. 


A10 


Appendix  A  DoD  Directive  3405, 1 


Appendix  B 
HQDA  LTR  25-90-1 


Tills  appendix  contains  the  text  of  HQDA  LTR  25-90-1  issued  on  i  July 
1990  which  provides  guidance  on  implementing  use  of  the  Ada  programming 
language  with  the  Department  of  the  Army. 
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DEFAKTKENT  OF  THE  ARMY 
WASHXNOTON,  D.C.  20310 

*HQDA  LTR  25-90-1 

*This  lattar  supsrssdas  KQDA  Letter  25-88-5,  21  June  1988. 
SAIS-ADO  (14  May  1990)  16  July  1990 

Expires  16  July  1992 

SUBJECT:  Implementation  of  the  Ada  Programming  Language 

SEE  DISTRIBUTION 

1.  Purpose.  This  letter  amplifies  Army  policy  and  guidelines 
for  implementing  the  Ad  programming  language  as  reguired  by  DOD 
Directives  3402.1  and  3405.2 

2.  References.  Related  publications  are  listed  below. 

a.  DOD  Directive  3405.1,  2  April  1987,  Computer  Programming 
Language  Policy. 

b.  DOD  Directive  3405.2,  30  March  1987,  Use  of  Ada  in  Weapon 
Systems . 

c.  AMSZ/MIL-STD-1815A-1983,  Ada  Programming  Language, 

22  January  1983. 

d.  HQDA  message,  0313O9Z  August  1987,  SQL  Relational  Data 
Base  Language  Standard. 

3.  Explanation  of  abbreviations.  Abbreviations  used  in  this 
letter  are  explained  in  the  glossary. 

4.  Applicability  and  scope.  This  letter  applies  to  all  computer 
resources  used  to  develop,  modify,  maintain,  or  support  Army 
software.  These  resources  include  but  are  not  limited  to 
automated  information  systems,  intelligence  systems,  tactical 
systems,  and  weapon  systems  that  have  information  resources  such 
as  computers  as  part  of,  or  embedded  in,  the  host  system.  They 
also  include  but  are  not  limited  to  systems  developed  by  or  for 
major  commands,  program  executive  of ficers/program  managers, 
central  design  activities,  cos^bat  development  facilities,  and 
laboratories.  Except  in  instances  noted  in  paragraph  6a,  this 
policy  needs  not  be  applied  retroactively  to  systems  that  have 
entered  full-scale  development  or  deployment  phases  of  the  life 
cycle,  or  for  which  a  waiver  has  been  approved  by  Headquarters, 
Department  of  the  Ax.tc  'KQDA) . 

5.  Responsibilitisis 

a.  The  Director  of  Information  Systems  for  Command,  Control, 
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CaumunlcatlonM,  and  Computers  (DXSC4)  will — 


(1)  Act  as  the  Army  Ada  Executive  Official  and  serve  as 
the  Army  focal  point  for  all  Ada  program  activitiea .  The  DISC4 
will  review  and  approve  all  reqiueets  for  exceptions  or  waivers 

<2)  Develop  and  execute  the  policy  and  plans  necessary  to 
ensure  successful  Army-wide  transition  to,  and  implementation  of, 
the  Ada  language  and  its  associated  technology,  including 
processes  for  software  engineering  and  software  engineering 
project  management. 

b.  Major  Army  command  (MACOM)  commanders  and/or  program 
executive  officers  (PEOs)  will-- 

(1)  Develop  appropriate  policy  to  support  an  Ada 
implementation  plan. 

(2)  Develop,  submit,  maintain,  and  execute  an  Ada 
implementation  plan  in  the  format  shown  in  Appendix  A.  The 
implementation  plan  will  be  in  two  parts  (systems  and 
organizational)  and  will  be  suhmitted/updated  on  an  annual  basis. 
The  systems  portion  will  address  all  major  systems  (such  as 
mission  critical  computer  resources  (MCCR) ,  Standard  Army 
Management  Information  System  (STAMXS),  command  standard,  command 
unigue,  and  multi-usar/location)  and  those  systems  that  provide 
input  to  or  receive  output  from  these  systems.  This  portion  will 
also  include  a  schedule  for  transition  to  Ada,  as  appropriate. 

The  organizational  portion  will  address  planning,  training,  and 
support  available  for  migrating  ^  ~  Ada  technology. 

(3)  Maintain,  as  a  FEO,  an  Ada  implementation  plan  for 
those  systems  tuidar  their  purview  and  ensure  that  assigned 
program/pro ject/produot  managers  (PMs)  implement  Ada  in 
accordance  with  Army  policy. 

(4)  Ensure  that  software  designers /developers  are  fully 
trained  in  the  use  of  the  Ada  language,  technology,  and  software 
engineering  processes,  with  particular  emphasis  on  developing 
components  that  are  tested,  validated,  and  documented  for 
inclusion  in  reuse  libraries. 

(5)  Ensure  that  military  and  government  civilian  personnel 
in  all  software  skill  groups  are  aware  of  new  advanced  software 
technologies  for  possible  implementation. 

(6)  Develop  procedures  and  guidelines  that  address  good 
software  engineering  principles  that,  as  a  minimum,  address 
software  reuse,  portability,  and  management  controls. 

c.  Heads  of  HQDA  activities  will  develop,  maintain,  and 
submit  implementation  plans  to  the  Department  of  the  Army 
Information  Manager  (DAIM)  for  execution.  The  HQDA  staff 
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«sr«nci««  and  thair  fiald  oparatlng  aganclas  (FOAs)  are  conaidarad 
oollactlvaly  as  a  MACOH  for  axacution  of  this  lattar. 

6.  Policy. 

a.  Tha  Ada  prograaming  languaga  as  dafinad  in  ANSI/MIL-STD- 
1815A-1983  la  tha  alngla,  aommon,  high  ordar  eomputar  programming 
languaga  for  all  computar  raaourcaa  uuad  In  tha  Army  unlasa 
anothar  languaga  la  mandatad  by  a  higher  laval  diractlva. 
Approvals  to  uaa  anothar  approvad  standard  high  ordar  languaga 
(KOb) ,  as  dafinad  in  DOD  Slreotlva  3405.1,  will  only  ba  grantad 
whan  tha  usa  of  tha  other  languaga  is  astlmatad/caloulatad  to  be 
mora  coat  affaotiva  or  mora  oparatlonally  affsotlva  over  tha 
applications'  Ufa  cycle.  Programming  languages  other  than  Ada 
that  ware  authorizad  and  ara  baing  usad  in  full-scale  development 
of  these  systems  may  oontinua  to  be  usad  through  deployment  and 
for  software  maintananoa.  In  those  specific  instances  where  Army 
systams  must  interface  with  non- Department  of  Defense  (DOD) 
agendas,  such  as  tha  Central  Intelligence  Agency  (CIA)  acid 
Federal  Bureau  of  Investigation  (FBI),  Ada  is  preferred  but  not 
raguired.  Existing  software  need  not  ba  rewritten  in  Ada  solely 
for  tha  purpose  of  converting  to  Ada.  All  systams,  however,  will 
transition  to  Ada  when  tha  next  hardware /software  upgrade 
raguiras  modification  of  mora  than  oua-third  of  tha  existing 
cods  over  tha  system  Ufa  cycle,  udass  a  waiver  is  obtained. 

b.  All  raoruasts  for  exceptions  to  usa  anothar  approvad  HOD 
will  have  fully  documented  rationale.  The  raguasts  will  address 
taohnical  feasibility  and  life-cycle  cost  analysis  or  cite  the 
applicable  higher  level  diractlva. 

G.  Whan  software  components  for  Army  systams  ara  being 
acguired  and/or  developed,  good  software  engineering  principles 
will  be  exercised  to  facilitate  tha  use  of  Ada.  Tha  approach  to 
acguiring  and/or  developing  software  components  will  be  based  on 
an  analysis  of  lifa-cycla  costs  and  operational  efficiency. 

Major  considerations  should  bat 

(1)  Tha  usa  or  modification  of  existing  Ada  software. 

(2)  The  use  of  off-the-shelf  software  and  advanced 
software  technology,  implamantad  in  other  than  Ada,  for  which  no 
modification  or  aovammant  maintenance  is  ragulrad.  Advanced 
software  technology  includes  software  tools,  life-cycle  support 
envi.  >nm«nt8,  nonprocedural  languages,  and  modem  database 
management  systems  (DBMSs)  that  provide  improvements  in 
productivity,  usability,  xaaintainability,  and  portability.  A 
waiver  is  not  reguired  for  non -developmental  item  (MDI)  software 
application  packages  and  advanced  software  technology  that  are 
not  modified  by  or  for  DOD.  In  those  instances  where  existing 
software  reguires  modification  to  ensure  the  total  system  meets 
reguirements,  a  waiver  is  reguired  if  more  than  one- third  of  the 
source  code  is  being  changed  and  the  changes  are  not  written  in 
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<a)  Regarding  the  use  of  fourth  generation  languages 
(4aLe),  the  following  apply: 

1  The  approved  ad  hoc  query  and  Dataibaae 
Management  System  interface  language  for  Army  systems  is  the 
Structured  Query  Language  (SQL),  Federal  Information  Processing 
Standard  (FIPS)  127.  In  accordamce  with  HQDA  message,  031309Z 
August  1987,  SQL  will  be  used  for  relational  databases  as  the 
interface  between  programs  and  the  supporting  DBMS.  A  waiver  is 
not  required  for  any  system  using  an  SQL-compliant  DBMS  in 
conjunction  with  Ada. 

2  Non-SQL-oompliant  4aLs  may  be  used  without  the 
requirement  for  a  waiver  to  develop  prototypes  during 
requirements  definition  and  in  short  term/ad  hoc  applications 
(less  than  3  years'  useful  life).  In  no  case  will  a  non-Ada 
prototype  be  fielded  during  system  implementation  nor  will  on  ad 
hoc  application  exceed  the  time  limitation  without  an  approved 
Ada  waiver. 

(b)  With  the  exception  noted  in  subparagraph  2,  above, 
4GLb  will  not  replace  the  requirement  for,  or  the  use  of  ,  Ada. 

(3)  The  development  of  new  Ada  software.  If  source  code 
generators  are  used  in  the  development  of  Ada  software,  they  must 
produce  an  Ada  source  code  that  complies  with  AMSI/HIL-STD-1815A- 
1963. 


(4)  The  impact  on  certain  critical  processes  that 
currently  cannot  be  performed  efficiently  in  an  HOL  due  to  timing 
and/or  sizing  constraints.  These  functions,  requiring  very  fast 
or  tightly  controlled  computer  processing,  are  more  appropriately 
written  at  the  machine  level  (for  example,  micro-code/assembly 
language) .  In  such  instances,  a  waiver  is  not  required  if  the 
ration  of  non- Ada  source  code  to  Ada  source  code  (terminal 
semicolon  count)  does  not  exceed  15  percent.  An  Ada  waiver  is 
required  if  the  total  machine  level  code  exceeds  10,000  lines. 

(5)  The  requirement  that  projects  use  a  validated  Ada 
compiler,  as  defined  by  the  Ada  Joint  Program  office  (AJFO)  Ada 
Compiler  Validation  Procedures,  at  the  start  of  formal  testing. 
Providing  no  changes  are  made  to  the  compiler,  it  may  be  used  for 
the  balance  of  the  project's  life  cycle  even  though  its 
associated  validation  certificate  may  have  expired,  if  the 
compiler  is  altered,  then  a  validation  is  necessary. 

d.  If  system  requirements  cannot  be  satisfied  by  paragraph 
6c,  then  a  waiver  approval  is  required  from  HQDA,  DISC4 
(SAIS-ADO)  to: 

(1)  Develop  Am^  software  in  another  computer  language. 
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(2)  Acquire  of£-the-ehelf  software,  implemented  in  other 
than  Ada,  which  requires  Gk>vammsnt  maintenance  or  modification 
of  more  than  one-third  of  tbs  total  system  software. 

(3)  Implement  a  system/ subsystem  in  a  4GL. 

(4)  Develop  an  Army  system,  with  severe  time  and/or  size 
constraints,  in  which  the  machine  level  to  Ada  source  code  ratio 
exceeds  15  percent  or  the  total  machine  lanquage  code  exceeds 
10,000  lines. 

e.  In  all  instances,  however,  anyone  requesting  a  waiver  must 
demonstrate  that  the  software  strategy  is  more  cost-effective  or 
more  operationally  effective  over  the  system  life  and  must 
include  a  statement  of  maintainability  from  the  responsible 
software  maintainer. 

7 .  Waivers 

a.  with  the  exception  noted  in  paragraph  6c,  a  waiver  must  be 
obtained  to  develop  any  non-Ada  software. 

b.  Justification  must  address  the  following  issues: 

(1)  The  waiver  request  will  provide  adequate  technical 
description  to  address  limitations,  documentation,  portability, 
maintainability,  and  usability  of  the  proposed  software  language 
or  package. 

(2)  The  waiver  request  will  provide  complete  life-cycle 
economic  rationale  for  both  Ada  and  the  requested  language.  For 
tactical  systems,  intelligence  systems,  and  embedded  weapon 
systems,  the  waiver  request  must  also  include  a  risk  analysis 
that  addresses  technical  performance  and  schedule  impact. 

c.  A  waiver  request  for  all  new  initiatives  must  be  approved 
prior  to  Milestone  I  approval.  Prototypes  may  use  advanced 
software  technology  (such  as  4QLs)  in  accordance  with  paragraph 
6c (2).  However,  sunk  costs  for  a  non-Ada  prototype  will  not  be 
considered  justification  for  a  waiver. 

d.  An  existing  system  undergoing  modification,  as  defined  in 
paragraph  €a,  must  have  received  a  waiver  prior  to  system 
redevelopment  regardless  of  the  cost. 

a.  The  long-term  costs  of  supporting  programmers, 
enviroiunsnts,  and  software  code  for  diverse  languages  will  be 
closely  scrutinized  when  waivers  are  considered. 

f.  Waivers  will  apply  only  to  the  specified  system  or 
subsystem  identified. 

g.  Waiver  processing  procedures  are  as  follows: 
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(1)  Wh«u  thars  in  a  P50/PH  atruoturs  in  placa  the  waiver 
regiuest  will  be  aubmltted  from  the  PM  through  the  PEO  (amd  MACOM 
i£  appropriate)  to  the  DISC4  (SAIS-ADO) .  Xll  reguests  will  have 
a  atatement  of  maintainability  from  the  applicable  Life  Cycle 
Hoftware  Engineering  Center  <LCSEC),  Software  Development  Center 
(SDC),  or  Government  software  engineering  organization  that  will 
be  responsible  for  maintenance  of  the  system. 

(2)  Mhen  there  is  no  PBO/PM  structure  in  place,  the  waiver 
reQ[uast  will  be  submitted  through  the  cognizant  software  support 
center  through  the  HXCOM  to  the  DISC4. 

(3)  Waivers  may  be  denied  at  any  level  but  can  only  be 
approved  by  the  DISC4. 

8.  Effective  date  and  implementation.  This  directive  is 
effective  immediately.  MACOM  Deputy  Chiefs  of  Staff  for 
Information  Management  (DCSlMs)  and  PEOs  will  forward  a  copy  of 
their  consolidated  initial /updated  Ada  implementation  plans 
(appendix  A)  to  HQDA  (SAXS-ADO)  Washington,  DC  20310-0107  by 
1  October  1990.  Updates  to  the  Ada  Implementation  Plan  are  due 
on  1  October  annually. 
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Appandix  A 


Ada  Syatai&a  Implanentation  Plan 

1.  MACOM/Zastallation 

2 .  POC  Nama/Talaphona 

3.  syscam  Naiaa  and  Acronym 

4 .  Currant  Lif a  Cycla  Hanagamant  Phaaa 

5 .  Systam  Fialdlng  Data 

6.  ADF  Hardwara  Usad 

7 .  Computar  Oparatlng  Systam 

8.  Softwara  Danguagas  Usad  by  Sub8y8tem(s)  Including  Support 
Sof twara 

a.  Nama 

b.  Linas  of  Coda 

c.  Parcant  of  Systam 

9.  Databaaa  Managamont  Syatam  (DBMS)  Usad 

10.  DBMS  Intarfaca  Tachnigua 

11.  Program  Dasign  Languaga/Zmplamantation  Languaga 

12.  Project  Approval  Dociu&antation  (Computar  Rasourcas  Managamant 
Plan  (CRMP),  Acguiaition  Plans,  and  ao  on,  with  status) 

13.  Data  Waivar  Approvad  (if  applicabla) 

14.  Ada  Transition  DAtas  (start  and  finish) 

15.  Planned  Cpgrada  Data(8)  (for  aithsr  hardwara  or  software) 

16.  Halntananca  Responsibility 

17 .  Systam  Documantation  Standard  Usad 

18.  Transition  to  Ada  (narrative  explanation) 

Ada  Organizational  Implementation  Plan 

1 .  H'nnan  Resources 

a  Education  and  Training  of  Zncurobant  Hanagamant 
and  Technical  Personnel 

b.  Accassion/Recruitmant  of  Qualified  Ada  Personnel 

c .  Ada  Support  Contractor 

2 .  Resources 

a.  Financial 

b.  Technical  Status 


(1) 

Ada 

Support  Environment  (including  intarfaca 

DOD 

Standard  1838) 

(2) 

Interface  to  Operational  Environment 

(a) 

DBMS 

(b) 

Operating  Systam 

Glossary 

(c) 

Graphics  Support 

Abbreviations 

ADP - 

--  automatic  data  processing 

AJPO - 

--  Ada  Joint  Prouram  Office 
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ANSI - Amarlcaii  National  Standards  Institute 

CIA  -  Central  Intelligence  Agency 

CRN?  -  Computer  Resources  Management  Plan 

QAIM - Department  o£  the  Army  Information  Manager 

DBMS  -  Database  Management  System 

DCSIM  -  Deputy  Chief  of  Staff  for  Information 

Management 

DISC4  - - -  Director  of  Information  Systems  for  Command 

Control f  Communications,  and  Computers 

DOD  -  Department  of  Defense 

FBI  - -  Federal  Bureau  of  Investigation 

40L  - - fourth-generation  language 

FIPS  - - - -  Federal  Information  Processing  Standards 

FOA  - -  field  operating  agency 

HOL  - - - - high  order  language 

HQDA.  - - -  Headguartere,  Department  of  the  Army 

LCSEC  -  Life  Cycle  Software  Engineering  Center 

MACOM - - - -  major  Army  command 

MCCR  -  mission  critical  computer  resources 

NDI  -  non-developmental  item 

PEO  -  program  executive  officer 

PM  -  program/project /product  manager 

POC - point  of  contact 

SDC  -  Software  Development  Center 

SQL  -  structured  query  language 

STAMIS  -  Standard  Army  Management  Information  System 

BY  ORDER  OF  THE  SECRETARY  OF  THE  ARMY; 
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MILTON  H.  HAMILTON 
Admlnintratlv*  Aaniatant  to  th« 
Sacratary  of  tha  Army 


DISTRIBUTION: 

HQDA 

(DACS-ZA) 

HQDA 

(SAFM) 

HQDA 

(SARD) 

HQDA 

(SAAA) 

HQDA 

(SAIS-ZA) 

HQDA 

(SAIG-ZA) 

HQDA 

(DAMI-ZA) 

HQDA 

(DALO-ZA) 

HQDA 

(DAMO-ZA) 

HQDA 

(DAFE-ZA) 

HQDA 

(DAEN-ZA) 

HQDA 

(DASO-ZA) 

HQDA 

(NGB-ZA) 

HQDA 

(DAAR-ZA) 

HQDA 

(DAJA-ZA) 

HQDA 

(DACH-ZA) 

COMMANDER-IN-CHIEF 

n.S.  ABMY,  SnjROPR  AND  SEVENTH  AHMY 
COMMANDERS 

EIGHTH  U.S.  ARMY 

FORCES  COMMAND 

U.S.  ARMY  MATERIEL  COMMAND 

U.S.  ARMY  TRAINING  AMD  DOCTRINE  COMMAND 

U.S.  ARMY  INFORMATION  SYSTEMS  COMMAND 

U.S.  ARMY  JAPAN 

U.S.  ARMY  WESTERN  COMMAND 

MILITARY  TRAFFIC  MANAGEMENT  COMMAND 

U.S.  ARMY  CRIMINAL  INVESTIGATION  COMMAND 

U.S.  ARMY  HEALTH  SERVICES  COMMAND 

U.S.  ARMY  SOXJTH 

SUPERINTENDENT,  U.S.  MILITARY  ACADEMY 
CF: 

HQDA  (SASA) 

HQDA  (SAUS) 

HQDA  (SACW) 

HQDA  (SAIL) 

HQDA  (SAMR) 

HQDA  (SAGC) 

HQDA  (SAAG-ZA) 

HQDA  (SALL) 

HQDA  (SAPA) 

HQDA  (SADBU) 

COMMANDERS 

U.S.  ARMY  MILITARY  DISTRICT  OF  WASHINGTON 
U.S.  ARMY  RECRUITING  COMMAND 
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DIRECTOR,  DEFENSE  LOGISTICS  AGENCY 
PROGRAM  EXECUTIVE  OFFICERS 
COMMUNICATIONS 

STANDARD  ARMY  MANAGEMENT  INFORMATION  SYSTEM 

COMMAND  AND  CONTROL  SYSTEMS 

STRATEGIC  INFORMATION  SYSTEMS 

ARMAMENTS 

CHEMICAL / NUCLEAR 

ARMORED  SYSTEMS  MODERNIZATION 

AVIATION 

COMBAT  SUPPORT 

FIRE  SUPPORT 

AIR  DEFENSE 

INTELLIGENCE  AND  ELECTRONIC  WARFARE 
STRATEGIC  DEFENSE 


I 

I 
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Appendix  C 

The  Congressional  Ada 

Mandate^ 


This  mandate  was  first  included  in  the  fiscal  year  1991  appropriations  bill 
(H.R.  5803)  for  the  Department  of  Defense.  That  bill  was  signed  by  the 
I’resident  on  November  5, 1990,  and  became  Public  Law  101-511.  In  the  FY 
1991  act,  the  section  number  and  wording  were; 

Sec.  8092.  Notwithstanding  any  other  provisions  of  law,  after  June 
1,  1991,  where  cost  effective,  all  Department  of  Defense  software 
shall  be  written  in  the  programming  language  Ada,  in  the  absence 
of  special  exemption  by  an  official  designated  by  the  Secretary  of 
Defense. 

Similar  wording  was  also  included  in  the  FY  1992  appropriations  bill.  Public 
Law  102-172,  enacted  November  26,  1991.  There,  the  mandate  can  be  found  in 
Section  8073.  The  FY  1991  appropriations  bill  originated  in  the  House  as  H.R. 
5803,  In  the  version  reported  out  of  the  House  and  sent  to  the  Senate,  this  sec¬ 
tion  (originally  numbered  Sec.  8084)  had  not  contained  the  proviso  "where  cost 
effective";  us  amended  by  the  Senate,  the  mandate  was  deleted  entirely;  when 
House  and  Senate  conferees  met  to  reconcile  differences  in  the  two  versions, 
they  restored  the  mandate  with  the  "where  cost  effective"  proviso.  With  this  pro¬ 
viso,  the  rnaridate  was  then  a  part  of  the  final  version  of  the  appropriations  bill 
passed  by  both  houses  and  signed  by  the  President.  The  following  appeared  in 
House  Report  101-822,  which  accompanied  the  original  House-passed  version  of 
H.R.  5803. 


'  Copyright  1992.  IIT  Research  Institute.  All  rights  assigned  to  the  U.S.  Government  (Ada  Joint 
Piogram  Office).  Permission  to  reprint  this  Ityer,  in  whole  or  in  part,  is  granted,  provided  the 
AdalC  is  acknowledged  as  the  source.  If  this  flyer  is  reprinted  as  part  of  a  published  document, 
please  send  a  courtesy  copy  of  the  publication  to  AdalC,  c/o  IIT  Research  Institute,  4600  Forbes 
Boulevard,  Lanhain,  MD  20706-4320.  The  AdalC  is  sponsored  by  the  Ada  Joint  Program  Office. 
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Ada  Programming  Language.  —  The  Department  of  Defense 
developed  Ada  to  reduce  the  cost  of  development  and  support  of 
software  systems  written  in  the  hundreds  of  languages  used  by  the 
DOD  through  the  early  1980s.  Beside  the  training  economies  of 
scale  arising  from  a  common  language,  Ada  enables  software  cost 
reduction  in  several  other  ways:  (1)  its  constructs  have  been 
chosen  to  be  building  blocks  for  disciplined  software  engineering; 
(2)  its  internal  checking  inhibits  errors  in  large  systems  lying 
beyond  the  feasibility  of  manual  checking;  and  (3)  its  separation  of 
software  module  interfaces  from  their  implementations  facilitates 
and  encourages  reuse  of  already-built  and  tested  program  parts. 
While  each  of  these  advantages  is  important,  Ada's  encouragement 
of  software  engineering  is  fundamental.  Software  practitioners 
increasingly  believe  the  application  of  engineering  disciplines  is 
the  only  currently-feasible  avenue  toward  controlling  unbridled 
software  cost  escalation  in  ever-larger  and  more  complex  systems. 
In  March,  1987,  the  Deputy  Secretary  of  Defense  mandated  use  of 
Ada  in  DOD  weapons  systems  and  strongly  recommended  it  for 
other  DOD  applications.  This  mandate  has  stimulated  the  develop¬ 
ment  of  commercially-available  Ada  compilers  and  support  tools 
that  are  fully  responsive  to  almost  all  DOD  requirements.  How¬ 
ever,  there  are  still  too  many  other  languages  being  used  in  the 
DOD,  and  thus  the  cost  benefits  of  Ada  are  being  substantially 
delayed.  Therefore,  the  Committee  has  included  a  new  general 
provision.  Section  8084,  that  enforces  the  DOD  policy  to  make  use 
of  Ada  mandatory.  It  will  remove  any  doubt  of  full  DOD  transition 
to  Ada,  particularly  in  other  than  weapons  systems  applications.  It 
will  stimulate  DOD  to  move  forward  quickly  with  Ada-based 
software  engineering  education  and  cataloguing/reuse  systems.  In 
addition,  U.S.  and  commercial  users  have  already  expanded 
tremendously  the  use  of  Ada  and  Ada-related  technology.  The 
DOD,  by  extending  its  Ada  mandate,  can  leverage  off  these  com¬ 
mercial  advances.  Navy  Ada  is  considered  to  be  the  same  as  Ada 
for  the  purposes  of  this  legislation,  and  the  term  Ada  is  otherwise 
defined  by  ANSI/MIL-STD-1815.  The  Committee  envisions  that 
the  Office  of  the  Secretary  of  Defense  will  administer  the  general 
provision  in  a  manner  that  prevents  disruption  to  weapon  systems 
that  are  well  into  development.  Tlie  Committee  directs  that  appli¬ 
cations  using  or  currently  planning  to  use  the  Enhanced  Modular 
Signal  Processor  (EMSP)  be  exempted  from  mandatory  use  of  Ada 
as  a  matter  of  policy. 
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Appendix  D 
Ada  vs.  C++ 


On  July  9, 1991,  the  Air  Force  released  to  the  public  a  report  of  a  business 
case  they  conducted  to  determine  under  A'hat  circumstances  a  waiver  to  the  DoD 
Ada  requirement  might  be  warranted  for  use  of  C++,  particularly  in  DoD’s  Cor¬ 
porate  Information  M^iagement  (CM)  program.  The  report  is  titled,  "Ada  and 
C++:  A  Business  Case  Aruilysis."* 

Since  its  release  the  report  has  '■eoeived  a  great  deal  of  publicity  in  various 
newspapers  and  journals.  The  information  that  follows  was  excerpted  from 
remarks  nade  by  Mr.  Lloyd  K.  Mosemann,  II  Deputy  Assistant  Secretary  of  the 
Air  Force  (Communications,  Computers,  and  Logistics),  at  a  press  conference 
held  July  9,  1991 , 

I.  Introduction 

I'here  has  never  been  any  intention  to  question  DoD’s  commitment  to  Ada, 
but  only  to  identify  when  waivers  for  C++  might  be  warranted.  This  business 
case  will  support  the  development  of  DoD  programming  language  policy  for 
information  systems  and  C3  systc  ms. 

I  might  say  at  the  outset  that  language  comparison  is  not  merely  a  scientific 
issue;  it  evokes  strong  emotions  as  well,  in  that  to  a  certain  extent  people  adopt 
"favurito"  languages  for  reasons  other  than  purely  dispassionate  analysis,  much 
as  one  n,('§ht  not  be  able  to  explain  why  he/she  roots  for  the  Chicago  Cubs  or 
drinks  Ccke  rather  than  Pepsi.  The  task  is  also  rendered  difficult  because  there 
are  yet  no  well-established  and  standard  methods  for  conducting  such 


’  Those  who  have  an  account  with  the  Defense  Technical  Information  Center  (DTIC)  mav 
purchase  "Ai'-i  and  C++:  A  Business  Case  Analysis’’  from  DTIC.  Cameron  Statioi..  Alexand’^ia. 
Virginia  2314,  ■/A3/y74-7633;  Order  No.  AD  A253  087;  Cost  $'20.82.  All  others  may  purchase  it 
from  the  National  Technical  Information  Service  (NTIS),  U.S.  Depaitmeni  of  Commerce.  5825 
hort  Royal  Road,  Springfield,  Virginia  22161,  703/487-4600:  Order  No.  AD  A253  087;  Cost 
$43.00. 
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comparisons.  For  these  reasons,  we  endeavored  to  make  our  study  as  quantita¬ 
tive  as  possible,  asking  the  best  experts  we  could  find  to  use  a  variety  of  methods 
that  have  historically  been  used  for  business  analysis  in  such  tasks.  We  felt  that 
by  using  a  variety  of  methods  and  comparing  their  results,  we  would  avoid  the 
skewing  that  might  result  from  the  sole  use  of  a  single  method. 

In  our  business  case,  therefore,  several  different  approaches  were  undertaken 
to  identify,  from  a  business  perspective,  when  the  life  cycle  cost  effectiveness  of 
C-f-t-  might  be  greater  than  that  of  Ada. 

•  The  first,  conducted  by  the  Institute  for  Defense  Analyses  (IDA),  examined 
quantitatively  the  availability  of  tools  and  training  for  the  two  languages. 

•  The  second,  conducted  by  the  Software  Engineering  Institute,  applied  to  this 
problem  a  quantitative  language  selection  methodology  developed  by  IBM 
for  the  Federal  Aviation  Administration  (FA A). 

•  The  third,  conducted  by  CTA,  Inc.,  analyzed  cost  and  cost  analysis. 

•  And  the  fourth,  conducted  by  the  TRW  Corporation,  applied  a  standard  cost 
model  in  depth  to  both  languages  for  a  typical  information  systems/C3  pro¬ 
ject  (micro  analysis). 

•  In  addition,  the  Naval  Postgraduate  School  (NPS)  was  asked  to  address  the 
overall  policy  issue  of  Ada,  particularly  in  the  context  of  emerging  fourth- 
generation  language  (4GL)  software  technology. 

Each  of  the  substudies  reached  the  same  conclusion:  there  are  no  compelling 
reasons  to  waive  the  Ada  requirement  to  use  C++. 

The  business  case  analysis  was  directed  at  information  systems  and  C3  sys¬ 
tems.  However,  there  is  no  reason  to  believe  the  results  would  differ  for  com¬ 
puter  programs  embedded  in  weapons  systems. 

Let  me  now  summarize  for  you  the  salient  quantitative  results  of  each  study, 
and  I  think  you  will  understand  more  fully  how  we  arrived  at  our  conclusion. 

II.  Substudy  Results. 

A.  Tools,  Environments,  and  Training:  IDA  Substudy. 

The  Institute  for  Defense  Analyses  (IDA)  collected  and  analyzed  information 
on  the  market  availability  of  commercial-  off-the-shelf  products  available  from 
U.S.  sources  for  Ada  and  C-H-t-  compilers,  tools,  education,  and  training.  The 
study  provided  a  large  quantity  of  demographic  data.  For  example,  there  are  28 
companies  located  in  the  U.S.  that  have  Ada  compilers  with  currently  validated 
status;  1 8  vendors  offer  C++  compilers.  The  Ada  compiler  vendors  are  more 
likely  to  have  been  in  business  five  years  or  more.  Ada  "validation"  is  more 
rigorous  than  that  of  other  high  order  languages:  only  Ada  is  monitored  and 
approved  for  conformity  to  a  standard,  without  supersets  or  subsets,  by  a 
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government-controlled  process.  By  contrast,  no  validation  or  even  a  standard  of 
any  kind  exists  for  C++,  although  a  standard  by  1994  is  expected. 

Both  languages  are  supported  on  PCs  and  workstations,  Ada  is  also  sup¬ 
ported  on  mainframes.  Ada,  but  not  C++,  has  cross  compilation  systems. 

Ada  is  supponed  with  program  engineering  tools.  Compiler  vendors  provide 
a  rich  set.  Code  generators  exist  for  Ada  but  none  so  far  for  C++.  There  is  con¬ 
siderable  variability  among  C++  products  in  language  features  supported  and 
libraries  provided. 

Ada  is  taught  in  43  states  at  223  universities  and  13  DoD  installations.  C++ 
is  taught  in  four  states  at  four  universities  and  no  DoD  installations.  There  are 
more  Ada  than  C++  courses  available.  The  cost  of  training  is  about  equal,  but 
Ada  course  variety  is  wider. 

B.  Faceted  IBM  Language  Selection  Methodology:  SEI  Substudy. 

The  Federal  Aviation  Administration  (FAA)  contracted  with  IBM  in  the 
mid-1980s  to  evaluate  high  order  languages  for  use  on  its  Advanced  Automation 
System  (AAS)  Program.  In  response,  IBM  developed  a  formal,  quantitative 
faceted  methodology  comparing  48  language  features  (criteria)  in  six  categories, 
This  IBM  study  concluded  that  use  of  Ada  was  "in  the  ultimate  best  interest  of 
the  AAS  program  and  its  goals,  and  that  warrants  coping  with  the  temporary 
risks /problems  that  loom  large  in  the  near  term  in  order  to  reap  the  significant 
benefits/payoffs  over  the  long  term." 

Using  this  same  methodology  for  each  of  the  48  criteria,  the  Software 
Engineering  Institute  (SEI)  evaluated  Ada  and  C++  for  application  in  informa¬ 
tion  systems/C3  systems.  The  original  FAA  weighted  scores  for  the  six  criteria 
categories  were  as  shown  in  this  matrix: 


Category 

Max. 

Ada 

C 

Pascal  JOVIAL 

FORTRAN 

Capability 

16.7 

6.1 

9.6 

10.4 

7.6 

3.9 

Efficiency 

16.4 

8.0 

11.8 

10.8 

11.0 

11.1 

Availability/Reliability 

22.6 

21.5 

11.6 

14.5 

15.6 

10.3 

Maintainability/Extensibiiity 

17.4 

14.0 

10.2 

12.2 

6.8 

8.3 

Lifecycle  cost 

11.3 

8.2 

7.4 

7.8 

4.9 

5.2 

Risk 

15.6 

8.8 

8.9 

7.6 

9,6 

8.2 

Total 

100.0 

76.6 

59.5 

63.3 

55.5 

47.0 

The  1991  weighted  scores  for  the  six  criteria  categories  were: 
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Category 

Max. 

Ada 

C++ 

Capability 

16.7 

15.3 

11.3 

Efficiency 

16.4 

10.7 

10.9 

Availability/Reliability 

22.6 

19.1 

12.6 

Maintainability/Extensibility 

17.4 

13.6 

11.4 

Lifecycle  cost 

11.3 

8.4 

8.0 

Risk 

15.6 

11.7 

9.8 

Total 

100.0 

78.8 

63.9 

In  1985  Ada  was  considered  considerably  more  capable  than  C.  Today,  the  SEI 
study  found  there  is  still  a  significant  difference  between  Ada  and  C++,  C’s  suc¬ 
cessor.  The  relative  efficiency  of  Ada  has  improved  markedly;  Ada  still  scores 
significantly  higher  in  availability/reliability;  the  Ada  advantage  in 
raaintainability/extensibility  persists;  and  from  a  position  of  parity  in  1985,  Ada 
has  attained  in  1991  a  significant  advantage  over  C++  in  lowered  risk. 

An  attachment  lists  numerous  major  Ada  information  systems/C3  systems.  It 
is  not  widely  appreciated  that  such  extensive  use  is  now  being  made  of  Ada:  in 
fact,  the  Ada  9X  Project  Office  reports  that  the  U.S.  Ada  market,  excluding  train¬ 
ing,  services,  and  government  research/development,  now  exceeds  $1  billion. 

C.  Macro  Cost  Analysis:  CTA  Substudy. 

CTA  compiled  and  compared  available  productivity  and  cost  data  of  Ada  and 
C++.  Much  of  their  data  comes  from  Reifer  Consultants’  extensive  database,  one 
of  the  best,  largest,  and  most  current  programming  language  cost  databases  now 
available. 

Average  productivity  across  the  four  domains  for  which  data  exists 
(environment/tools,  telecommunications,  test  (with  simulators)  and  other)  for 
both  Ada  and  C++  projects  is  shown  in  this  matrix.  Note  the  productivity  advan¬ 
tage  for  Ada: 


Productivity 

(SLOC/MM) 

Number  of 
Data  Points 

Norm  (ail  languages) 

183 

543 

Average  (Ada) 

210 

153 

Average  (C++) 

187 

23 

First  project  (Ada) 

152 

38 

First  project  (C++) 

161 

7 

The  C++  project  data  reflected  informaiion  on  23  projects  talcen  from  seven  firms 
who  had  been  using  C++,  Unix,  and  object-oriented  techniques  for  over  2  years. 
All  projects  were  new  developments.  Application  :ii7.e  ranged  from  25  to  500 
KSLOCs  (thousand  source  lines  of  code).  Avei+ge  size  was  about  100  KSLOC. 
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The  average  costs  across  the  four  domains  for  both  Ada  and  C++  projects  are 
shown  in  this  matrix. 


Cost 

Number  of 

($/SLOC) 

Data  Points 

Cost  (all  languages) 

$70 

543 

Average  (Ada) 

65 

153 

Average  (C++) 

55 

23 

Typically,  the  Ada  developments  were  performed  in  accordance  with  inilitary 
standards  and  incorporated  formal  reviews,  additional  documentation,  and  addi¬ 
tional  engineering  support  activities  such  as  formal  quality  assurance  (QA)  and 
configuration  management  (CM).  Most  C++  projects  are  commercial  and  do  not 
extensively  incorporate  such  activities.  Additionally,  on  such  projects  develop¬ 
ers  are  typically  intimately  involved  with  users,  resulting  in  considerably  less 
requirements  engineering  effort.  Consequently,  applications  on  which  C++  is 
used  ate  inherently  less  costly,  so  that  the  reported  productivity  rates  are  favor¬ 
ably  skewed  toward  C++. 

The  average  error  rates  across  the  four  domains  for  both  Ada  and  C++  pro¬ 
jects  were: 


Integration 
Error  Rates 
(Errors/KSLOC) 

FQT 

Error  Rates 
(Errors/KSLOC) 

Number  of 
Data 
Points 

Norm  (all  languages) 

33 

3 

543 

Average  (Ada) 

24 

1 

153 

Average  (C++) 

31 

3 

23 

The  integration  error  rates  include  all  errors  caught  in  test  from  start  of  integra¬ 
tion  testing  until  completion  of  software  Formal  Qualification  Test  (FQT).  The 
FQT  error  rate  includes  only  those  errors  found  during  the  FQT  process. 

A  so-called  "transition  state  analysis"  performed  by  Reifer’s  group  indicates 
that  26  of  the  38  firms  within  the  Ada  database  had  successfully  made  the 
changeover  to  effective  use  of  Ada,  while  none  of  the  7  firms  in  the  C++  data¬ 
base  had  made  the  transition.  Also,  none  of  the  7  firms  were  fully  using  C++’s 
inheritance  and  other  advanced  features. 

The  standardization  maturity  of  Ada  was  found  by  the  CTA  to  be  particularly 
important.  While  Ada  has  a  firm  and  well  policed  standard,  allowing  neither 
supersets  nor  subsets,  it  will  be  years  before  a  stable  C++  language  specification 
is  established.  New  features  are  being  considered  for  the  latest  standard  C++ 
release.  Vendors  are  likely  to  offer  their  own  enhanced  versions  of  C++  com¬ 
pilers  and  CASE  tools,  complicating  portability  and  reuse. 
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Finally,  the  original  arguments  for  establishing  a  single  programming 
language  for  military  applications  were  found  to  remain.  Common  training, 
tools,  understanding,  and  standards  simplify  acquisition,  support,  and  mainte¬ 
nance.  The  study  concluded  that  after  maturing  for  a  decade,  Ada’s  benefits  have 
been  proven  for  all  application  classes.  Ada  projects  have  reported  15%  higher 
productivity  with  increased  quality  and  double  the  average  size.  Normalizing 
these  data  to  comparable  size  projects  would  result  in  an  expected  Ada  produc¬ 
tivity  advantage  of  about  35%.  Ada  should  be  the  near*  term  language  of  choice. 
C4-+,  the  study  felt,  still  needs  significant  maturing  before  it  is  a  lov/  risk  solution 
for  a  large  DoD  application. 

D.  Micro  Cost  Analysis:  TRW  Substudy. 

TRW  performed  a  tradeoff  analysis  that  generalized  recent  corporate  cost 
analyses  on  a  typical  real-world  information  systems/C3  systems  project.  Their 
study  defined  a  set  of  maximally  independent  criteria,  judged  each  language  with 
respect  to  those  criteria,  and  then  translated  those  judgments  into  cost  impacts  to 
emphasize  the  importance  of  each  criterion  from  a  lifecycle  cost  perspective. 
Results  were  translated  into  perturbations  of  Boehm’s  Ada  COCOMO  cost 
model. 

Rankings  of  the  two  languages  based  on  this  analysis  are  shown  in  this  matrix 
(0  =  no  support;  5  =  excellent  support),  followed  by  a  total  score,  a  weighted  sum 
of  the  rankings  based  on  weights  determined  by  an  expert  panel: 
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Category 

Ada 

C++ 

Reliable  SA/V  Engineering 

4.5 

3.2 

Maintainable  SA/V  Engineering 

4.4 

3.2 

Reusable  SA/V  Engineering 

4.1 

3.8 

Realtime  SAA/  Engineering 

4.1 

2.8 

Portable  SA/V  Engineering 

3.6 

2.9 

Runtime  Performance 

3.0 

3.6 

Compile-Time  Performance 

2.3 

3.1 

Multilingual  Support 

3.1 

2.4 

OOD/Abstraction  Support 

3.9 

4.6 

Program  Support  Environment 

4.1 

2.1 

Readability 

4.4 

2.9 

Writeability 

3.4 

3.5 

Large  Scale  SA/V  Engineering 

4.9 

3.3 

COTS  SA/V  Integration 

2.8 

3.6 

Precedent  Experience 

3.6 

1.5 

Popularity 

2.8 

4.0 

Existing  Skill  Base 

3.0 

1.8 

Acceptance 

2.5 

3.3 

Total  Score  for  Mgt  Info  Systems 

1631 

1324 

(Ada  score  is  23%  higher) 

Total  Score  for  C3  Systems 

1738 

1401 

(Ada  score  is  24%  higher) 

The  study  concluded  that  both  Ada  and  C++  represent  improved  vehicles  for 
software  engineering  of  higher  quality  products.  Currently,  C++  was  estimated 
to  be  approximately  3  years  behind  Ada  in  its  maturity  and  tool  support.  The 
case  study  used  in  this  report  (the  Cotnmand  Center  Processing  and  Display 
System-  Replacement)  demonstrated  development  cost  advantages  for  Ada  on 
the  order  of  35%  and  maintenance  cost  advantages  for  Ada  on  the  order  of  70% 
under  today’s  technologies.  In  the  far  term  (1994+),  the  study  felt,  this  Ada 
advantage  might  erode  to  approximately  a  10%  advantage  in  development  costs 
and  30%  in  maintenance  costs  for  a  typical  development  intensive  system, 

The  study  listed  the  primary  strengths  of  Ada  as  its  support  for  realtime 
domains  and  large  scale  program  development.  Its  primary  weaknesses  are  its 
cnmpile-tirne  and  runtime  efficiency.  The  primary  strengths  of  C++  listed  were 
its  support  for  better  object  oriented  design,  support  for  COTS  integration,  and 
its  compile-tiine  and  runtime  efficiency.  Its  main  weaknesses  were  identified  as 
its  support  for  reliability  and  large  scale  program  development.  In  general,  the 
study  felt  Ada’s  weaknesses  to  be  solved  by  ever-increasing  hardware  perfor¬ 
mance  and  compiler  technology  advancement.  C++  weaknesses,  on  the  other 
hand,  remain  to  be  solved  by  advances  in  its  support  environment, 

E.  Ada  Policy  Issues:  NFS  Study. 
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Concurrently  with  the  preparation  of  this  Ada  and  C++  Business  Case 
Analysis,  the  Naval  Postgraduate  School  (NFS)  reported  on  policy  issues  on  the 
use  of  Ada  for  Management  Information  Systems.  Their  report,  an  analysis  of 
the  need  to  see  Ada  in  a  total  and  evolving  context,  is  an  important  vision  state¬ 
ment  leading  from  Ada  as  the  primary  third-generation  language  (3GL)  to  its 
conception  as  the  basis  for  evolving  to  higher  levels  of  productivity  in  so-called 
3  1/2  GL  and  4GL  environments. 

Rather  than  concentrating  on  programming  language  selection,  the  NPS 
report  focuses  on  and  argues  for  needed  advances  in  software  development  tech¬ 
nology.  In  particular,  the  Report  contends,  while  traditional  factors  such  as  pro¬ 
gramming  language  selection,  better  training,  and  computer-assisted  software 
engineering  (CASE)  tools  can  enhance  productivity  modestly,  a  fundamental 
change  in  the  software  development  paradigm  will  be  necessary  to  achieve  an 
order  of  magnitude  gain.  Such  a  gain  is  possible  through  use  of  4GLs,  languages 
that  will  ultimately  enable  the  developer  to  define  the  complete  design  of  an 
application  entirely  in  the  4GL’s  own  high-level  specification  language.  The 
specification  is  then  translated  automatically  by  the  4GL  into  an  executable  pro¬ 
gram.  When  accompanied  by  a  productive  development  environment,  an  evolu¬ 
tionary  implementation  methodology,  and  well  trained  development  teams,  the 
report  asserts,  4CiLs  can  provide  a  tenfold  gain  in  productivity. 

An  intermediate  step  cited  by  the  report  in  the  movement  to  4GLs  is  3  1/2  GL 
programming,  a  term  referring  to  the  extensive  use  of  CASE  tools  coupled  with  a 
high  level  of  code  reuse.  Tlie  3  1/2  GL  approach  requires  a  strong  commitment 
to  codifying  and  accrediting  code  modules,  to  the  point  where  it  becomes  easier 
and  more  desirable  to  reuse  code  than  to  rewrite  it. 

Although  experience  with  4GLs  has  not  yet  been  extensive  (with  existing 
experience  limited  largely  to  specific  functional  domains  such  as  financial 
management  and  transaction  processing),  4GLs  are  attractive  for  several  reasons. 
One  is  their  robustness  under  change;  changes  made  to  the  application,  for  what¬ 
ever  reason,  are  made  at  the  specification  level  and  then  re-  translated  automati¬ 
cally  into  executable  code.  Another  is  the  facility  with  which  they  can  be 
integrated  into  tightly  knit  and  full-featured  development  environments.  For 
these  reasons,  the  report  strongly  recommends  that  the  DoD  discourage  u,se  of 
traditional  3GL  programming  and  take  bold  steps  to  incorporate  the  4GL  para¬ 
digm. 

Finally,  the  report  recommends  that,  given  the  importance  of  Ada  to  DoD 
software,  greater  effort  and  funding  should  be  provided  for  the  key  Ada  initia¬ 
tives:  the  Ada  Technology  Improvement  Program,  Ada  9X,  and  Ada  education 
initiatives. 

Two  issues  on  3  1/2  GLs  and  4GLs  related  to  this  business  case  were  outside 
the  scope  of  the  NPS  report.  The  first  of  these  is  that,  for  the  foreseeable  future, 
state-of-the-art  limitations  will  probably  keep  4GL,s  from  generating  more  than 
half  the  total  code  required  by  most  applications.  In  such  cases,  where  a  substan¬ 
tial  amount  of  3GL  programming  will  be  required  to  complete  application 
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development,  use  of  a  3  1/2  GL  approach,  rather  than  a  4GL  approach,  is  prefer¬ 
able. 

Another  issue  outside  the  scope  of  the  NPS  Report  was  the  evaluation  of  the 
relative  merits  of  Ada  and  C+-i-  as  target  (output)  languages  for  4GL  application 
generators.  However,  as  section  V.C  of  the  NPS  report  points  out,  a  "standard, 
stable  target  language  portable  to  a  variety  of  hardware  platforms"  with  good 
software  reuse  and  interface  definition  capabilities  is  appealing.  Although  more 
study  of  the  characteristics  desired  in  4GL  target  languages  is  warranted,  the  SEI 
and  TRW  substudies  suggest  no  particular  advantage  of  C+-t-  over  Ada  in 
software  reuse  and  interface  definition,  so  there  appears  no  reason  to  waive 
DoD’s  Ada  requirement  in  favor  of  C++  as  a  target  language  for  4GLs. 

III.  Conclusions. 

All  four  substudies  which  specifically  compared  Ada  and  C++  (IDA,  SEI, 
CTA,  TRW)  report  a  significant  near  term  Ada  advantage  over  C++  for  all 
categories  of  systems.  This  advantage  could  be  eroded  as  C++  and  its  support¬ 
ing  environments  mature  over  the  next  few  years.  On  the  other  hand,  as  aggres¬ 
sive  overseas  Ada  initiatives  stimulate  even  wider  domestic  Ada  interest,  as  Ada 
tools/env'ronments  further  mature,  and  when  the  Ada  update  (Ada  9X)  is  com¬ 
plete,  the  balance  could  tip  further  in  Ada’s  favor. 

Adding  to  the  case  for  Ada  is  the  fact  that  the  Ada  scoring  so  well  in  the  busi¬ 
ness  case  was  Ada’s  1983  version,  MIL-STD-1815A.  Just  as  C++  incorporates 
into  C  certain  software  engineering  concepts  already  in  Ada  (e.g.,  modularity, 
strong  typing,  specification  of  interfaces),  so  an  Ada  update  now  underway  will 
bring  into  Ada  selected  features  now  included  in  C++.  This  update,  known  as 
the  Ada  9X  Project,  is  targeted  for  completion  in  1993.  The  product  of  extensive 
community  involvement  (including  the  C3  and  MIS  communities),  Ada  9X  will 
bring  to  Ada  such  improvements  as  decimal  arithmetic,  international  character 
sets,  improved  input/output,  support  for  calls  between  Ada  and  other  languages, 
further  representation  specifications,  and  inheritance/polymorphism  (popular 
features  of  C++).  The  Ada  9X  Project  Office  lists  one  of  the  goals  of  Ada  9X  as 
"to  provide  all  the  flexibility  of  C++  with  the  safety,  reliability,  and  understanda- 
bility  of  Ada  83." 

At  the  same  time,  Ada  9X  has  been  designed  so  that  neither  existing  Ada 
benefits  nor  performance  will  be  lost.  For  example,  Ada  9X  inheritance  will  be 
controlled  so  as  not  to  reduce  lifecycle  supportability.  Some  have  criticized 
OOP  features  such  as  inheritance  as  potentially  dangerous  to  DOD  software  mis¬ 
sion  goals  (such  as  safety,  reliability,  and  dependability). 

Bjame  Stroustrup  himself,  the  originator  of  C++,  has  been  quoted  as  follows: 
"C  makes  it  easy  for  you  to  shoot  yourself  in  the  foot.  C++  makes  that  harder, 
but  when  you  do,  it  blows  away  your  whole  leg." 

In  summary,  it  is  not  possible  to  make  a  credible  case  for  the  existence  of 
classes  of  "more  cost  effective"  C++  sy.stems  compared  to  Ada,  Business  cost 
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effectiveness  data  collected  for  this  study  are  typified  by  the  TRW  study’s  con¬ 
clusion  that  Ada  provides  development  cost  advantages  on  the  order  of  35%  and 
maintenance  cost  advantages  on  the  order  of  70%.  In  terms  of  full  lifecycle 
costs,  it  will  be  some  time  before  data  exists  which  could  justify  a  cost  savings 
for  C++.  Today,  there  is  limited  lifecycle  data  available  for  Ada  and  almost  none 
for  C++. 

For  the  foreseeable  future,  then,  this  business  case  shows  that  there  are  more 
than  enough  reasons  for  the  DoD  to  stick  firmly  with  Ada,  both  for  all  high  order 
language  (3GL  and  3  1/2  GL)  development  and  for  exclusive  use  as  a  target 
language  of  4GL  application  generators  in  the  large  class  of  applications  for 
which  3GL  code  must  supplement  generated  code. 
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Selected  Ada  Vendors 


Company; 

Products: 


Address: 


Company; 

Products: 

Address: 


Company: 

Products: 

Address: 


Company: 

Products: 

Address: 


Company; 

Products: 


Address: 


AdaSoft 

AdaManager/AdaQuest,  AdaMentor  Computer  Managed  Instruc¬ 
tion  System,  Graphical  Modeling  System  (SL-GMS),  AdaSofl 
Graphical  User  Interface  (GUI),  AdaSoft  Textual  User  Interface 
(TUI). 

AdaSoft,  Inc.,  8750-9  Cherry  Lane,  Laurel,  MD  20707;  Voice; 
(301)  725-7014;  FAX:  (301)  725-0980. 

AETECH 

Ada  Workstation  Environment  (AWE),  XAda  APSE. 

AETECH,  5841  Edison  Place,  Suite  1 10,  Carlsbad,  CA  92008; 
Voice:  (619)  43 1-7714;  FAX:  (619)  431-0860, 

Alsys 

Ada  compilers  for  a  variety  of  platforms. 

Alsys,  Inc.,  67  S.  Bedord  St.,  Burlington,  MA  01803-5152;  Voice; 
(617)  270-0030;  FAX;  (617)  270-6882. 

Cadre  Technologies 

Teamwork  (software  engineering  tool  set). 

Cadre  Technologies,  222  Richmond  Street,  Providence,  RI  02903; 
Voice;  (401)  351-CASE;  FAX:  (401)  351-7380. 

Caine,  Farber  &  Gordon 

PDL/81,  a  program  design  language  which  aids  in  the  design  and 
documentation  of  software.  It  is  available  for  DOS,  UNIX,  and 
VAX  platforms. 

Caine,  Farber  &  Gordon,  Inc.,  1010  East  Union  Street,  Pasadena, 
CA  91 106r;  Voice:  (800)  424-3070;  Voice:  (818)  449-3070;  FAX: 
(818)440-1742. 
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Company:  Dynamics  Research  Corporation 

Products;  AdaMat. 

Address:  Dynamics  Research  Corporation,  60  Frontage  Road,  Andover, 

MA  01810;  Voice:  (800)  522-7321. 

Company:  EVB  Software  Engineering 

Products;  Complexity  Measurement  Tool  (CMT),  GRAMMI  (interface 

builder). 

Address:  EVB  Software  Engineering.  5303  Spectrum  Drive,  Frederick,  MD 

21701;  Voice:  (301)  695-6960;  FAX:  (301)695-7734. 

Company;  Fastrak  Training 

Products:  Ada  training  and  consulting. 

Address:  Quany  Park  Place,  Suite  300,  9175  Guilford  Road,  Columbia, 

MD  21046-1802;  Voice:  (301)  924-0050;  FAX:  (301)  924-3049. 

Company:  Idaho  National  Engineering  Laboratory 

Products:  AdaSAGE. 

Address:  Idalio  National  Engineering  Laboratory,  EG&G  Idaho,  Inc.,  Spe¬ 

cial  Applications  Unit,  P.  O.  Box  1625,  Idaho  Falls,  ID  83415- 
1609;  Voice:  (208)  526-0656. 

Company:  Interactive  Development  Environments 

Products:  Software  Tlirough  Pictures  (Ada  development  environment). 

Address:  Interactive  Development  Environments  595  Market  Street,  10th 

Floor,  San  Francisco,  CA  94105;  Voice;  (800)  888-IDEl ;  Voice; 
(415)  543-0900;  FAX:  (415)  543-0145. 

Company;  Irvine  Compiler  Corporation 

Products:  ICC  Ada,  an  Ada  compiler  for  the  HP  9000  Models  300,  400,  700, 

and  800,  as  well  as  a  number  of  cross  compilers. 

Address:  Irvine  Compiler  Corporation,  34  Executive  Park,  Suite  270, 

Ii-vine,  CA  92714;  Voice:  (714)  250-1366;  FAX:  (714)  250-0676; 
E-mail:  jkohli@irvine.com. 

Company:  Meridian  Software  Systems 

Products:  The  AdaVantage  compiler  for  PCs  and  some  UNIX  workstations. 

Address:  Meridian  Software  Systems.  10  Pasteur  St.,  Irvine,  CA  92718; 

Voice:  (800)  221-2522;  Voice:  (714)  727-0700;  FAX:  (714)  727- 
3583. 

Company:  R.  &  R.  Software 

Products:  Ada  compilers  for  PCs. 

Address:  R.  &  R.  Software,  Inc.,  P.  O.  Box  1512,  Madison,  WI  53701 ; 

Voice:  (800)  722-3248;  Voice:  (608)  244-6436. 

Company:  Rational 

Products:  The  Rational  Environment,  Rational  Rose. 
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Address: 


Rational,  2800  San  Tomas  Expressway,  Santa  Clara,  CA  95051- 
0951;  Voice:  (408)  496-3600;  FAX:  (408)  496-3636. 


Company:  P.  P.  Texel  &  Company 

Products:  Ada  training  and  consulting. 

Address:  Victoria  Plaza,  Building  4,  Suite  9, 615  Hope  Road,  Eatontown, 

NJ  07724;  Voice:  (908)  922-6323. 

Company:  Verdix  Corporation 

Products:  self-hosted  compilers  (VADSSelf),  cross  compilers  (VADSCross), 

and  Ada  Programming  Support  Environment  (VADS  APSE). 
Address:  Verdix  Corporation,  14130-A  Sullyfield  Circle,  Chantilly,  VA 

22021;  Voice:  (703)  318-5800. 


Appendix  F 

Ada-Related  Organizations 


Organization:  ACM  Special  Interest  Group  on  Ada  (SIGAda) 

Synopsis:  ACM,  founded  in  1947,  is  the  oldest  of  association  for  computing 

professions ',s.  It  sponsors  a  number  of  special  interest  groups 
(SIGs)  of  which  SIGAda  is  one.  SIGAda  promotes  interest  in  and 
study  of  the  Ada  programming  language.  Its  monthly  publication 
is  Ada  Letters  t$20/year  for  ACM  members,  $4 2/year  others). 
POC  Mark  Gerhardt,  ESL,  Inc.,  495  Java  Drive.  MS  M507,  Sunnyvale, 

CA  94088-3510;  VOICE;  (408)  752-  2459;  E-mail: 
gerhardt@ajpo.sei.cmu.edu. 


Organization:  Ada  Joint  Program  Office  ( AJPO) 

Synopsis:  The  Ada  Joint  Program  Office  (AJPO)  was  established  in 

December  1980.  Its  activities  include  validating  Ada  compilers, 
supporting  the  development  and  distribution  of  software  tools  for 
Ada,  and  ensuring  that  Ada-related  efforts  of  the  various  services 
complement,  not  duplicate,  one  another.  In  this  capacity,  AJPO  is 
responsible  for  managing  efforts  to  provide  training  and  life-cycle 
support  for  Ada. 

POC:  John  Solomond,  The  Ada  Joint  Program  Office,  The  Pentagon, 

Room  3Eil4,  Washington,  DC  20301-3080;  Voice:  (703)  614- 
0208;  E-mail:  solomond@ajpo.sei.cmu.edu. 


Organization:  Software  Engineering  Institute  (SEl) 

Synopsis:  Realizing  that  the  defense  of  the  U.S.  is  increasingly  dependent 

on  computer-based  systems,  the  DoD  established  the  Software 
Engineering  Institute  (SEI)  at  Carnegie  Mellon  University  in 
December  1984.  The  SEl  staff,  drawn  from  academia,  govern¬ 
ment,  and  ind  istry  consists  of  approximately  250  technical  and 
support  personnel.  They  are  engaged  in  various  research  and 
development  activities  designed  to  improve  the  quality  of 
software  systems  and  of  the  software  engineering  process.  The 
ultimate  goal  of  the  SEl  is  to  change  this  process  from  a  labor- 
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POC: 


Organization 

Synopsis 
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intensive  craft  to  a  well-managed  mass-production  oriented 
activity. 

Customer  Relations.  Software  Hngineering  Institute.  Canie^oe 
Mellon  University,  Pittsburgh.  PA  1  .‘-21  .^3890;  Voice  (412) 
268-5800 

Software  Technology  Supjxm  Center  (STSCi 
The  STSC.  located  at  the  Ogden  Air  Logistics  Center  ( Al-MCi, 
Hill  Air  Porte  Ba.sc.  Utah,  was  established  by  HO  I'SAl  to  pro 
mote  development  and  managenseni  ot  tixils.  methods,  and 
environments  lorsottware  production  throughout  the  services 
Suit  ware  Icchnoiogy  Support  Center.  Attn  Cusiomer  Service. 
(Kt-ALC/TlSP.  Hill  APB.  UT  8405(>.  \uue  -801  -  MU\ 
PAX  (.Sill  , '"  StttiM 
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Ada  Events  Calendar^ 


Tlie  Ada  h\ent<>  C^lcndir  int.lude<k  inlnmutiun  un  upcoming  Ada  cunter- 
cnccs.  eu  It  liwu  onh  those  pr^igranis  with  hxed  dates,  and  dues  nut  include 
programs,  such  as  classes,  that  arc  scheduled  un  a  continuing  basis  Note,  how- 
eser.  that  mans,  if  not  most,  of  the  conferences  listed  below  are  conducted  on  an 
annula  basis 


Dale 

hseni 

Location 

Stxinsor 

Ssnopsis 


K)C 


Darr 

Event 

Location: 

Sponsor: 

POC 


October  5-7,  1992 

bih  SEl  Conlcrence  on  Software  Engineering  Education 
Hyatt  Islandia  Hotel,  San  Dtego.  California 
Software  Engineering  Institute 

The  SEl  Conference  on  Software  Engineering  Education  is  an 
annual  conference  that  brings  together  educators  from  universi¬ 
ties.  industry  ,  and  government  to  discuss  issues  related  to  the  con¬ 
tent.  structure,  and  delivery  of  software  engineering  education. 
The  conference  formal  includes  refened  papers,  panel  discus¬ 
sions.  reports,  tutorials,  and  workshop  sessions. 

Mary  Ellen  Rizzo.  Software  Engineering  Institute,  Carnegie  Mel¬ 
lon  University,  Pittsburgh,  PA  15213;  Tel:  412/268-3007;  FAX: 
412/268-5758;  Internet:  mer@sei.cmu.edu. 

October  14-15,  1992 
ASIS  Technical  Meeting 

Institute  for  Defense  Analyses  (IDA),  Alexandria,  VA 
IDA 

Clyde  Robey.  IDA.  Tel:  703/845-0666. 


c:up)nght  1992  IIT  Research  Institute.  All  rights  assigned  to  the  U.S.  Govemmem  (Ada  Joint 
Piogram  Office)  Permission  to  reprint  this  dyer,  in  whole  or  in  part,  is  granted,  provided  ihe 
AdalC  IS  acknowledged  as  the  source.  If  this  flyer  is  reprinted  as  part  of  a  published  document, 
please  send  a  courtesy  copy  of  the  publication  to  AdalC,  do  IIT  Research  Institute.  4600  Forbes 
Boulevard.  Lanham.  MD  20706-4320.  The  AdalC  is  sponsored  by  the  Ada  Joint  FYogram  Office. 
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Date: 

Event: 

Location: 

Sponsor: 


POC: 


Date: 

Event; 

Location: 

POC 


Date : 
Event: 
Locution: 
Synopsis: 


POC: 


Date: 

Event: 

Synopsis: 


POC: 


Date: 

Event: 

Location: 

Synopsis; 


October  14-15,  1992 
Ada  UK  International  Conference 
Britannia  International  Hotel,  London 
Ada  Language  UK,  Ltd. 

Helen  Byard,  Administrator,  Ada  UK.  P.O.  322,  York  YOl  3GY. 
England;  Tel;  (UK) 0904  412740;  Fax:  :UK)0904  426702. 

November  9-13.  1992 

Third  Eurospacc  Ada  in  Aero.space  Symposium 
Vienna.  Austna 

Ms.  Rosy  Piet.  Eurospace,  16bi,s.  Avenue  Bousquel.  F-7.S(X)7 
Pans.  France;  Tel:  +33-1-45  55  83  53;  Fax  +33-1-45  51  99  23 


November  16-20.  1992 
TRl-Ada  *92 

Orange  County  Convention  Center.  Orlando.  FI.. 

The  annua)  TRl-Ada  Conference  and  ExjHisiiion  is  the  Ada 
community's  largest  and  most  prestigious  event  TRl-Ada,  as  its 
name  implies,  reaches  out  and  bnngs  together  three  broad  bases 
in  the  Ada  community — government,  industry  ,  and  academia- 
with  a  program  that  covers  all  issues  ol  importance  to  Ada 
interests  The  theme  for  this  year’s  conlerence  is.  “The  Business 
of  Ada." 

TRl-Ada  '92.  Danieli  &  O'Keefe  As.sociates,  Inc  .  Conference 
Management.  Chiswick  Park.  490  Boston  Post  Road.  Sudbun. . 
MA  01776  USA 

December  2-3, 1992 

NASA/GSFC  Software  Engineering  Laboratory  (SEL)  7th  Annual 
Software  Engineering  Workshop 

The  workshop  is  an  annual  forum  where  software  practitioners 
exchange  information  on  the  mea.surement,  utilization,  and 
evaluation  of  .software  methods,  modcis,  and  tools.  There  will  be 
a  presentation  of  approximately  15  papers.  Papers  are  being  soli¬ 
cited  which  include  the  following  topics:  experiments  in  software 
development  or  management;  experiences  with  software  tools, 
models,  methodologies;  software  measures;  software  reu.se; 
software  process  assessment  and  improvement. 

Mr.  Mark  Cushion,  NA.SA/Goddard  Space  Flight  Center,  Code 
552.  Greenbelt,  MD  20771,  USA;  Phone:  (301)  286-6347;  FAX; 
(301)286-9183 

December  7-1 1,  1992 

Toulouse  '92:  Fifth  international  Conference  on  Software 
Engineering  &  Its  Applications 
Toulouse,  France 

Methods,  tools,  standards,  and  organization  are  the  major  aspects 
of  software  engineering  covered  by  the  conference.  The  confer¬ 
ence  will  include  tutorials,  exhibits,  and  an  industrial  foiuiri. 
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Date; 

Event: 

Location. 

Sponsors: 

Synopsis: 


POC; 


Dale: 

Event: 

Date: 

Event: 

Location: 

Synopsis: 


POC: 


Dale: 

Event: 

Location: 

Synopsis: 


POC: 


Jean-Cleaude  Rault,  EC2, 269  rue  de  la  Garenne,  F-92024  Nan- 
terre  Cedex,  France;  Tel:  +33-1-47  80  70  00;  Fax:  +33-1-47  80  66 
29 

December  8-10, 1992 
STARS  ’92 

Omni  Shoreham  Hotel,  Washington,  D.C. 

STARS,  Boeing,  IBM,  Paramax 

Megaprogramming  concepts,  the  firm  foundation  in  products, 
relevant  successes,  and  upcoming  plans  will  be  discussed  at  the 
program.  Integration  of  process  and  reuse  within  the  Software 
Technology  for  Adaptable  Reliable  Systems  (STARS)  environ¬ 
ment  will  be  demonstr*.ted.  There  will  be  exhibits  of  megapro¬ 
gramming  work  in  progi  ^ss  by  STARS  as  well  as  affiliates  and 
subcontractors,  Evening  inceptions  will  facilitate  networking 
with  government  and  industry  leaders. 

The  STARS  '92  Conference  Center.  3  Church  Circle  -  Suite  194, 
Annapolis,  MD  21401;  Fax:  (410)  267-C332;  E-Mail;  STARS92- 
Desk®  STARS.Rossyln.Uni.sys.com 

December  10,  1992 
Ada's  Birthday 

March  15-18,  1993 

1 1th  Annual  National  Conference  on  Ada  Technology 
Williamsburg  Hilton  and  National  Conference  Center,  Willi¬ 
amsburg,  Virginia. 

The  emphasis  for  this  conference  will  be  software  engineering, 
while  continuing  to  emphasize  Ada  as  an  important  building 
block.  Papers  on  applied  aspects  of  software  engineering  and  also 
experimentation  and  research  are  being  accepted.  Presenters  must 
register  for  the  Conference. 

ANCOAT  93,  c/o  Rosenberg  &  Risingcr,  1 1 287  W  Washingtr  .i 
Blvd.,  Culver  City.  CA  90230,  (310)  397-6338 

March  21-23,  1993 

5th  Annual  Oregon  Workshop  on  Software  Metnes 
Silver  Falls  State  Conference  Center,  Portland  Oregon 
The  Annual  Oregon  Workshop  on  Softw'are  was  founded  to  allow 
the  interchange  of  ideas  and  experiences  be:ween  those  using 
metrics  and  those  performing  research  in  me  area.  Call  for  parti¬ 
cipation  is  sought  from  both  practitioners  and  researchers.  Parti¬ 
cipation  may  consist  of  delivering  a  paper,  organizing  and  leading 
a  panel  session,  or  leading  a  mini  tutorial  on  some  aspect  of 
software  measurement. 

Warren  Harrison.  Center  for  Software  Quality  Research.  Portland 
State  University,  Portland,  OR  97207-0/5 1 ;  (503)  725-3 108; 
warren@cs.pdx.edu 
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March  24-26, 1993 

Second  International  Workshop  on  Software  Reusability 
Lucca,  Italy 

IEEE  Computer  Society,  ACM  SIGSOFT 
The  themes  for  this  year’s  workshop  include  methods,  tools  and 
environments,  reuse  library  methods,  generative  approaches  to 
reuse,  constructive  approaches  to  reuse,  theoretical  aspects  of 
reuse,  organizational  and  management  techniques  for  implement¬ 
ing  reuse,  domain  analysis  methods  and  techniques.  Attendance 
is  limited  to  100. 

April  18-23,  1993 

Fifth  Annual  Software  Technology  Conference 

Red  Lion  Hotel  &  Salt  Palace  Convention  Center,  Salt  Lake  City, 

Utah 

U.S.  Army,  U.S.  Navy,  U.S.  Air  Force 
Software  -  The  Force  Multiplier 

The  program  will  include  tutorials,  vendor  demonstrations, 
presentations,  and  "birds-of-a-feather"  discussion  groups.  The 
theme  for  this  year’s  conference  is,  “Software  -  The  Force  Multi¬ 
plier.’’  General  sessions  will  address  management  infonnation 
systems,  embedded  computers,  and  command  and  control.  Pro¬ 
posed  topics  for  presentations  include  reuse,  environments,  Ada 
implementation,  software  inspections,  change  management, 
object  oriented  programming,  automated  software  process  enact¬ 
ment.  metrics,  re-engineering,  software  engineering,  software 
ntaintenance,  DoD  software  initiatives,  configuration  manage¬ 
ment,  and  software  process  improvement. 

Dana  Dovenbarger,  Conference  Manager.  Software  Technology 
Support  Center.  OO-ALC/TISE,  Hill  AFB,  UT  84056;  Phone: 
(801 )  777-741 1 ;  DSN  458-741 1 ;  FAX:  (801 )  777-8069 

May  17-21,  1993 

ICSE:  15th  International  Conference  on  Software  Engineering 
Baltimore,  MD. 

IEEE  Computer  Society  Technical  Committee  on  Software 
Engineering  and  ACM  Special  Interest  Group  on  Software 
Engineering. 

June  14-18,  1993 
Ada  Europe 
Paris,  France 

Ada  Europe  '93,  AFCET.  156  Bd.  Pereire,  75017  Paris,  France 

September  18-23,  1993 
TRI-Ada  '93 
Seattle,  Washington 

The  theme  for  the  1993  conference  is,  “The  Management  and 
Engineering  of  Software.” 
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Appendix  H 
Glossary  of  Acronyms 


ACE 

ACM 

ACVC 

Ada 

ADA 

ADA 

Ada-IC 

AdaJUG 

AIC 

ALRM 

AJPO 

ANNA 

APSE 

ASAP 

ASEET 

ASR 

ATIP 

CAIS 

CARDS 

CASE 

CMU 

COSMIC 

CREASE 

DACS 

DARPA 

DIANA 

DID 

DTIC 

FIPS 

GRACE 

GRAMMI 

HOL 


Ada  Command  Environment  (STARS) 

Association  for  Computing  Machinery 
Ada  Compiler  Validation  Capability  (AJPO) 

Not  an  acronym 
American  Dental  Association 
Americans  with  Disabilities  Act 
Ada  Information  Clearinghouse 
Ada  Joint  User's  Group 
Ada  Information  Clearinghouse 
Ada  Language  Reference  Manual 
Ada  Joint  Program  Office 
ANNotaled  Ada  (Stanford  University) 

Ada  Progi  mming  Support  Environment 

Ada  Static  source  code  Analyzer  Program 

Ada  Software  Engineering  Education  and  training  Team 

Ada  Software  Repository 

Ada  Technology  Insertiort  Program  (AJPO) 

Common  APSE  Interface  Set 
Central  Archive  for  Reusable  Defense  Software 
Computer  Aided  Software  Engineering 
Camegie-Mellon  University 

computer  Software  Management  a:  Information  Center  (NA,SA) 

Catalog  of  Resources  for  Education  m  Ada  and  Software  Engineering 

Data  and  Analysis  Center  for  Software 

Defense  Advanced  Research  Projects  Agency 

Distributed  Intermediate  Attributed  Notation  for  Ada 

Data  Item  Description 

Defense  Technical  Information  Center 

Federal  Information  Processing  Standard 

Generic  Reusable  Ada  Components  for  Engineering  (EVB) 

Generated  Reusable  Ada  Man  Machine  Interface  (ESL) 

High  Order  Language 
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HOLWG 
IDD 
IEEE 
IEEE  CS 
IPSE 
KAPSE 
KIT 
KLOC 
LOG 
LRM 
MAPSE 
MIL-STD 
NBS 
NISE 
NIST 
NUMWG 
00 
OOA 
OOD 
OOP 
OOSD 
PCTE 
PDL 
PIWG 
RADC 
RIACS 
SAME 
SDD 
SE 
SEI 
SGML 
SIGAda 
SIGPLAN 
SIGSOFt 
SQA 
SJPO 
STARS 
STSC 
VADS 
WADAS 


High  Order  Language  Working  Group 

Interface  Design  Document 

Institute  for  Electrical  and  Electronic  Engineers 

IEEE  Computer  Society 

Integrated  Project  Support  Environment 

Kernel  APSE 

KAPSE  Interface  Team 

Thousand  LOG 

Lines  Of  Code 

Language  Reference  Manual 

Minimal  APSE 

Military  Standard 

National  Bureau  of  Standards  (obsolete,  now  NIST) 

NASA  Initiative  on  Software  Engineering 

National  Institute  for  Standards  and  Technology  (formerly  NBS) 

NUMerics  Working  Group  (SIGAda) 

Object  Oriented 

Object  Oriented  Analysis 

Object  Oriented  Design 

Object  Oriented  Programming 

Object  Oriented  Structured  Design 

Portable  Common  Tool  Environment  (ESPRIT) 

Program  Design  Language 

Performance  Issues  Working  Group  (SIGAda) 

Rome  Air  Development  Center 

Research  Institute  for  Advanced  Computer  Science  (NASA) 
SQL  Ada  Module  Extension 
Software  Design  Document 
Software  Engineering 

Software  Engineering  Institute  (Carnegie  Mellon  University) 
Standard  Generalized  Markup  Language 
Special  Interest  Group  on  Ada  (ACM) 

Special  Interest  Group  on  Programming  LANguages 

Special  Interest  Group  on  SOFTware 

Software  Quality  Assurance 

STARS  Joint  Program  Office 

Software  Technology  for  Adaptable  Reliable  Systems 

Software  Technology  Support  Center 

Verdix  Ada  Devciopmeni  System  (Verdix) 

Washington  Ada  Symposium 


Appendix  H  Glossary  o(  Acronyms 


12a.  OISTRIBUTION/AVAILABILITY  STATEMENT  I  12b.  DISTRIBUTION  CODE 


Approved  for  public  release;  distribution  is  unlimited 


13.  ABSTRACT  (Maximum  200  words) 

This  report  addresses  issues  relevant  to  the  transition  to  the  use  of  Ada  from  a  Corps  of  Engineers  perspective. 
The  direct  discussion  of  these  issues  is  preceded  by  background  material  on  Ada  itself.  First,  the  Department 
of  Defense  (DoD)  software  crisis  that  led  to  the  development  of  Ada  is  described  and  the  causes  underlying  it 
are  discussed.  Next,  a  brief  history  of  Ada  is  presented  to  show  how  it  fits  into  the  Government’s  approach  to 
meeting  the  crisis.  This  includes  a  discussion  of  the  guidelines  which  apply  to  the  use  of  Ada,  specifically  the 
Congressional  mandate  to  use  Ada  and  the  pertinent  DoD  and  Army  regulations.  The  second  major  section  of 
this  report  discusses  the  Corps  transition  to  Ada.  This  transition  will  involve  not  only  a  change  in  the  program¬ 
ming  language  u.sed  by  the  Corps,  but  also  a  change  in  development  philosophy;  software  engineering  princi¬ 
ples  must  be  incorporated  into  the  development  process  for  the  transition  to  be  successful.  The  various  issues 
to  be  addressed  by  the  Corps  in  order  to  accomplish  this  are  then  presented.  The  report  concludes  with  recom¬ 
mendations  concerning  practical  steps  Corps  development  sites  can  take  to  ensure  a  successful  transition  to  the 
use  of  Ada. 


14.  SUBJECT  TERMS 

Ada.  software  engineering.  Rational  Environment 

_ 

15.  NUMBER  OF  PAGES 

104 

16.  PRICE  CODE 

17  security  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 

18.  SECURITY  CLASSIFICATION  19.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE  1  OF  ABSTRACT 

UNCLASSIFIED  ' 

20.  LIMITATION  OF  ABSTRACT 

NSN  7540-01-280-5500  Standard  Fur-.t  290  (Rev.  2-89) 


Prescfib«d  by  ANSI  Sid  239-18 
298-102 


